Nice-to-have fix for autogen.sh

Pete Batard pete at akeo.ie
Wed Feb 1 06:21:47 EST 2012


On 2012.02.01 10:58, Segher Boessenkool wrote:
>> Actually I also do not like to have the configure line
>> in autogen.sh.
>
> Me neither. Any other opinions?

Really?

That's how all of the autogen.sh I know behave, and I very much prefer 
having configure invoked by autogen.sh than have to do it manually post 
autogen, if that's what you have in mind.

The reasoning behind this is that:
o autogen.sh is only used by maintainers - official distributions would 
have a configure (and Makefile) ready to use, so no need for autogen.
o maintainers have a fairly good idea of the options they want to have 
by default during development (--enable-maintainer-mode, debugging on, 
etc.) so they might as well enable them while accepting extra configure 
options through the use of $*. For instance, if you want to disable 
shared libraries in configure, you can do so through "./autogen.sh 
--disable-shared". You can also disable stuff that is enabled from 
autogen like this
o if you're going to be rebuilding a lot from a clean tree, it saves 
time not to have to invoke 2 autogen and then configure.

Now, with regards to fine tuning the options autogen should pass to 
configure that's another story, but the ones we have right now make a 
lot of sense to me.

>> ./configure --enable-maintainer-mode --enable-debug-log \
>> --enable-examples-build $*
>>
>> The line is not nice for release build since it enables verbose
>> debug log,

This is a false problem.

Releases will only provide a configure, not any of the files that 
configure produces. Thus you could have an autogen.sh that has an option 
that nobody else wants and it won't matter, since you're not going to 
provide Makefiles that were generated by configure using that option. 
Instead you're going to provide the _default_ Makefile.in's, as 
generated by autoconf/automake => none of the configure options from 
autogen will trickle down to the users.

The users will always have to run configure themselves, which of course 
makes sense, else it would mean that, besides logging or examples, we 
would also force a specific arch and all the other stuff that configure 
is meant to setup

Regards,

/Pete



More information about the libusbx mailing list