Nice-to-have fix for autogen.sh

[Vitali Lovich]

I think the point is that there should be a second autogen for custom-downstream builds that build from the repository (i.e. not source tarballs).

-Vitali

On Feb 1, 2012, at 3:21 AM, Pete Batard wrote:

> 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
> 
> _______________________________________________
> libusbx mailing list
> libusbx at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libusbx