2012/5/1 Pete Batard <p...@akeo.ie>: > On 2012.05.01 16:56, Uri Lublin wrote: >> For example usefull when running autogen.sh in src-dir and >> running configure in a (different) build-dir. > > We had a discussion previously (on a different mailing list) about > removing the call to configure altogether, but the outcome was fairly > mixed, as some of us see the running of configure in autogen.sh as quite > beneficial on systems where autotools is slow (typically Windows).
If the only benefit of running ./configure in autogen.sh is speed on Windows I propose to use an opt-in option and run ./configure only on Windows or if requested. The code would be something like: if [ -n "$CONFIGURE" ]; then ./configure --enable-maintainer-mode --enable-examples-build $* fi Maybe add an automatic detection of the Windows system to enable it by default on Windows. > I think the idea of using an environmental variable is a good > compromise, and I don't have much of an objection to it, but like Peter, > I would like to know if NOCONFIGURE is something that you have seen > being used in other projects. I found some references: - glib [1] uses $NOCONFIGURE - gst-editor [2] uses ./autogen.sh --noconfigure If the default is to call ./configure I would like to be able to select the opt-out option by just (and permanently) creating a file like .noconfigure. I know I will always/often forget to set NOCONFIGURE before running autogen.sh and will then lose time by running ./configure twice. Bye [1] http://mail.gnome.org/archives/commits-list/2010-June/msg09728.html [2] http://code.google.com/p/gst-editor/wiki/Installing -- Dr. Ludovic Rousseau ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel