configure output summary
Hi, when running configure, lots of somewhat important messages scroll by, like "silently disabling something you need" :-) An untrained eye may miss these easily, leading to confusion afterwards (I'm currently running a lecture on RADIUS, and pretty much all of my students took their time figuring out that they need openssl-devel for PEAP to work etc.). I think it would generally make sense to put a summary output of configure at the end of its run, so that one can easily see which modules will be disabled. In an acute case of bash script fiddling, I created the attached proof of concept "test.sh" script, which recursively goes through all config.log files and a) greps all lines with WARNING b) greps all lines with "silently not building" and puts these out in massaged human-readable form. Would something like this have any chances of getting included into the tarball? It could run as the very last thing in configure... Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
Stefan Winter wrote:
when running configure, lots of somewhat important messages scroll by, like "silently disabling something you need" :-)
Well... yes.
An untrained eye may miss these easily, leading to confusion afterwards (I'm currently running a lecture on RADIUS, and pretty much all of my students took their time figuring out that they need openssl-devel for PEAP to work etc.).
If it doesn't do SSL, the server prints out large warnings when you first start it in debugging mode.
I think it would generally make sense to put a summary output of configure at the end of its run, so that one can easily see which modules will be disabled.
See the "MODULES" entry in the top-level "Make.inc" file. That contains the list of modules which the server tries to build. The "OPENSSL_LIBS" entry in the same file also shows whether or not OpenSSL is enable. If it's empty, there's no OpenSSL.
In an acute case of bash script fiddling, I created the attached proof of concept "test.sh" script, which recursively goes through all config.log files and
a) greps all lines with WARNING b) greps all lines with "silently not building"
"grep -R" is a Linux-ism. :( I still like portable code.
and puts these out in massaged human-readable form. Would something like this have any chances of getting included into the tarball? It could run as the very last thing in configure...
Much simpler, and much less work: - print out MODULES line from "Make.inc" - look for "OPENSSL_LIBS". If it's not there, warn that PEAP, etc. will be disabled. The only real issue is that the list of modules to build is *large*. So people might still ignore it when it's being printed out. But some simple processing / pretty-printing might make it easier to read. Alan DeKok.
Hi,
when running configure, lots of somewhat important messages scroll by, like "silently disabling something you need" :-)
./configure --with-whatever-options | grep WARN ;-) there are other packages that print out stuff at the end about what features are not enabled etc - but , being on those mailing lists too, noone reads that output....even if you put a whacking great big dragon in it ;-) alan
Hi,
when running configure, lots of somewhat important messages scroll by, like "silently disabling something you need" :-) ./configure --with-whatever-options | grep WARN
;-)
Yes, I can do that. I even dare say that I can spot WARNINGs while the scroll buffer runs by, and thus instantly see what's going wrong (at least on my slow-spec'd VMs). But newcomers aren't that trained yet. You shouldn't have to tell them "every other Linux project does "configure", but you have to "configure | grep WARN" - it's odd if you're not used to it.
there are other packages that print out stuff at the end about what features are not enabled etc - but , being on those mailing lists too, noone reads that output....even if you put a whacking great big dragon in it ;-)
Exactly these projects were the role model I had in mind. Granted, some people will even overlook the necessary information if it is in <blink>RED</blink>. But a summary at the end at least raises chances of problems being flagged by the person running configure. Interesting discussion elsewhere in the thread... a proper solution to the problem would indeed be that the recursiveness of configure goes away. Much better than running a whacky script, of course! Greetings, Stefan -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
On 2010/11/19 08:55 AM, Stefan Winter wrote:
away. Much better than running a whacky script, of course!
I feel that adding the script cannot do any harm whatsoever. I agree that a lot of newbies will not read it, but if _one_ person reads it a month, it will mean less questions on the list! Cheers, -- Johan Meiring Cape PC Services CC Tel: (021) 883-8271 Fax: (021) 886-7782
On Fri, Nov 19, 2010 at 09:21:11AM +0200, Johan Meiring wrote:
I agree that a lot of newbies will not read it, but if _one_ person reads it a month, it will mean less questions on the list!
That's actually the wrong solution to that particular problem. Newbies should stop compiling whenever they can use binary packages and avoid the whole issue. -- 2. That which causes joy or happiness.
On Wed, Nov 17, 2010 at 07:53:02AM +0100, Stefan Winter wrote:
I think it would generally make sense to put a summary output of configure at the end of its run, so that one can easily see which modules will be disabled.
In an acute case of bash script fiddling, I created the attached proof of concept "test.sh" script, which recursively goes through all config.log files and
a) greps all lines with WARNING b) greps all lines with "silently not building"
and puts these out in massaged human-readable form. Would something like this have any chances of getting included into the tarball? It could run as the very last thing in configure...
I've actually been a bit confused by the notion of having separate autoconf installations/invocation in multiple subdirectories. The point of that would seem to be that if you just want to reconfigure and rebuild one particular part, you can do it. But who ever does that? It seems to me that everyone only ever wants a single autoconf instance for the whole tree, which can generate all the subdirectory makefiles. -- 2. That which causes joy or happiness.
Josip Rodin wrote:
I've actually been a bit confused by the notion of having separate autoconf installations/invocation in multiple subdirectories. The point of that would seem to be that if you just want to reconfigure and rebuild one particular part, you can do it.
But who ever does that?
Exactly.
It seems to me that everyone only ever wants a single autoconf instance for the whole tree, which can generate all the subdirectory makefiles.
Ugh. Even better, use a build system which includes header/library checking as part of the dependencies. Waf && others seem to be a good start here. For 2.2.x, I've been looking at getting rid of libtool && libltdl. All modern systems have dlopen(), so that makes things easier. Getting rid of autoconf would be a logical next step. Alan DeKok.
On 11/18/2010 08:21 AM, Josip Rodin wrote:
I've actually been a bit confused by the notion of having separate autoconf installations/invocation in multiple subdirectories. The point of that would seem to be that if you just want to reconfigure and rebuild one particular part, you can do it.
But who ever does that?
It seems to me that everyone only ever wants a single autoconf instance for the whole tree, which can generate all the subdirectory makefiles.
Yeah, I've never quite understood that either, but it works which at the end of the day is what matters most even if it seems odd. If someone ever does decide to work on the build tools I wonder if it might make sense to abandon autotools. I've used autotools for years and it's been a love/hate relationship. I love it when someone else has done the work, but hate it whenever I have to create new autotools functionality or it breaks (which sadly is often) and I have to debug it. It's baroque complexity is daunting and it often suffers from versioning issues. FWIW, a number of projects I have some involvement with are switching over to CMake. It's still to early for me to give a report card on CMake, but it's an interesting trend. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
On Thu, Nov 18, 2010 at 08:48:38AM -0500, John Dennis wrote:
On 11/18/2010 08:21 AM, Josip Rodin wrote:
I've actually been a bit confused by the notion of having separate autoconf installations/invocation in multiple subdirectories. The point of that would seem to be that if you just want to reconfigure and rebuild one particular part, you can do it.
But who ever does that?
It seems to me that everyone only ever wants a single autoconf instance for the whole tree, which can generate all the subdirectory makefiles.
Yeah, I've never quite understood that either, but it works which at the end of the day is what matters most even if it seems odd.
If someone ever does decide to work on the build tools I wonder if it might make sense to abandon autotools.
I personally have no problem with autoconf per se, configure.ac syntax in general tends to be fairly clear to me. But having N copies where we only seem to need 1? That sounds like a problem. Also I think that this line of reasoning "it's apparent that it's odd, few understand it, yet it works, so let's either keep it or attempt to replace it completely" is problematic in and of itself. We must be able to fully understand our own code, and the requirements that led to it, in order to be able to both try to fix the problems in the existing solution *and* to be able to attempt a successful replacement. If we don't, it's likely that we're just going to end up repeating old problems and making things worse. So it would be good if we could first get an authoritative opinion on whether support for subdirectory reconfiguration is actually necessary, or if perhaps it's a remnant of some other unrelated idea. Alan? I've had some experience analyzing auto*-based build systems on other things I've packaged, which seemed to result in them becoming less obfuscated, so I could have a crack at this one if it's possible. -- 2. That which causes joy or happiness.
Josip Rodin wrote:
I personally have no problem with autoconf per se, configure.ac syntax in general tends to be fairly clear to me. But having N copies where we only seem to need 1? That sounds like a problem.
Yes. The repetition is annoying.
Also I think that this line of reasoning "it's apparent that it's odd, few understand it, yet it works, so let's either keep it or attempt to replace it completely" is problematic in and of itself. We must be able to fully understand our own code, and the requirements that led to it, in order to be able to both try to fix the problems in the existing solution *and* to be able to attempt a successful replacement. If we don't, it's likely that we're just going to end up repeating old problems and making things worse.
The existing code works (mostly). That's why it's still using an old version of libtool && libltld: I tried changing it, it was a PITA, and it had problems.
So it would be good if we could first get an authoritative opinion on whether support for subdirectory reconfiguration is actually necessary, or if perhaps it's a remnant of some other unrelated idea. Alan?
It's so that the modules are independent of the core. If you don't like a module "rm -rf" the directory. If you want a new one, drop files into a subdirectory, and the main configure/build process will find them.
I've had some experience analyzing auto*-based build systems on other things I've packaged, which seemed to result in them becoming less obfuscated, so I could have a crack at this one if it's possible.
If you can make it simpler, OK. Alan DeKok.
On Thu, Nov 18, 2010 at 05:16:03PM +0100, Alan DeKok wrote:
It's so that the modules are independent of the core. If you don't like a module "rm -rf" the directory. If you want a new one, drop files into a subdirectory, and the main configure/build process will find them.
OK, that's actually a legitimate requirement. It should be possible to solve this problem with much less overhead. -- 2. That which causes joy or happiness.
participants (6)
-
Alan Buxey -
Alan DeKok -
Johan Meiring -
John Dennis -
Josip Rodin -
Stefan Winter