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

Reply via email to