Boost.Build changes for 1.38
As we're nearing 1.37, and the time for big changes that follows after, I wanted to discuss one Boost.Build change I want to make. Right now, we have two ways to build Boost -- using bjam directly, and using configure and make (which are wrappers over boost.build). The first approach may be a bit hard, and the second is very nice when it works, but it leads to other problems: - users start to assume it's "real" configure, and get upset when various variables that CXXFLAGS have no effect - if users want to do anything custom, like mingw cross compilation, they have to go back to direct use of bjam anyway. So, I'd like to suggest a solution where building of boost involves three steps: 1. ./bootstrap.sh or ./bootstrap.bat This step just builds bjam and puts it into boost root 2. ./bjam [--build-type=complete] [--layout=xxx] [properties] configure This step: - Tries to detect what compilers you have - Figures which optional libraries you have, and which you don't (e.g. ICU) - Writes a file project-config.jam with all the discovered information. 3. ./bjam This step can be usually invoked with no parameters, reads the configuration information from project-config.jam, and builds everything. For new users, this solution is only marginally more complex that configure/make, and does not create the false impression it's autoconf. For power users, the file produced in (2) can be tweaked and extra options can be specified in (3). For all users, this means that various properties can be specified only once in (2) and need not be repeated on every build, which is clearly a convenient thing. Anybody has comments about this plan? - Volodya -- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build V2: http://boost.org/boost-build2
I'm interested in the process whereby these changes occur. I would like to see a) trunk testing continue with the "last release" of bjam. b) the trunk testing to include testing of at least one boost tool - bjam. c) when trunk testing passes, then boost build changes can be merged into the release - just as a normal library. At this point, the Boost Build from the release ready branch would be used by trunk testing. It's my understanding that boost.build has its own test suite so implementing trunk testing should entail little or no extra work. Though I would expect that as in testing of libraries, new problems motivate the addition of new tests. This is a good thing. I believe that this would make implementing big changes in boost build easier for everyone. Robert Ramey Vladimir Prus wrote:
As we're nearing 1.37, and the time for big changes that follows after, I wanted to discuss one Boost.Build change I want to make.
Right now, we have two ways to build Boost -- using bjam directly, and using configure and make (which are wrappers over boost.build). The first approach may be a bit hard, and the second is very nice when it works, but it leads to other problems:
- users start to assume it's "real" configure, and get upset when various variables that CXXFLAGS have no effect - if users want to do anything custom, like mingw cross compilation, they have to go back to direct use of bjam anyway.
So, I'd like to suggest a solution where building of boost involves three steps:
1. ./bootstrap.sh or ./bootstrap.bat This step just builds bjam and puts it into boost root
2. ./bjam [--build-type=complete] [--layout=xxx] [properties] configure This step: - Tries to detect what compilers you have - Figures which optional libraries you have, and which you don't (e.g. ICU) - Writes a file project-config.jam with all the discovered information.
3. ./bjam This step can be usually invoked with no parameters, reads the configuration information from project-config.jam, and builds everything.
For new users, this solution is only marginally more complex that configure/make, and does not create the false impression it's autoconf. For power users, the file produced in (2) can be tweaked and extra options can be specified in (3). For all users, this means that various properties can be specified only once in (2) and need not be repeated on every build, which is clearly a convenient thing.
Anybody has comments about this plan?
- Volodya
Robert Ramey wrote:
I'm interested in the process whereby these changes occur.
I would like to see
a) trunk testing continue with the "last release" of bjam. b) the trunk testing to include testing of at least one boost tool - bjam. c) when trunk testing passes, then boost build changes can be merged into the release - just as a normal library. At this point, the Boost Build from the release ready branch would be used by trunk testing.
It's my understanding that boost.build has its own test suite so implementing trunk testing should entail little or no extra work. Though I would expect that as in testing of libraries, new problems motivate the addition of new tests. This is a good thing.
I believe that this would make implementing big changes in boost build easier for everyone.
I'll see if I'll be work on including Boost.Build tests in the matrix fast enough to make it for 1.38. (As practice shows, if any failures turn up they are hard to fix without actual access to the system running tests, so I not sure how much gain it will be) - Volodya
on Sat Nov 01 2008, Vladimir Prus <ghost-AT-cs.msu.su> wrote:
As we're nearing 1.37, and the time for big changes that follows after, I wanted to discuss one Boost.Build change I want to make.
Right now, we have two ways to build Boost -- using bjam directly, and using configure and make (which are wrappers over boost.build). The first approach may be a bit hard, and the second is very nice when it works, but it leads to other problems:
- users start to assume it's "real" configure, and get upset when various variables that CXXFLAGS have no effect - if users want to do anything custom, like mingw cross compilation, they have to go back to direct use of bjam anyway.
So, I'd like to suggest a solution where building of boost involves three steps:
1. ./bootstrap.sh or ./bootstrap.bat This step just builds bjam and puts it into boost root
2. ./bjam [--build-type=complete] [--layout=xxx] [properties] configure This step: - Tries to detect what compilers you have - Figures which optional libraries you have, and which you don't (e.g. ICU) - Writes a file project-config.jam with all the discovered information.
3. ./bjam This step can be usually invoked with no parameters, reads the configuration information from project-config.jam, and builds everything.
For new users, this solution is only marginally more complex that configure/make, and does not create the false impression it's autoconf. For power users, the file produced in (2) can be tweaked and extra options can be specified in (3). For all users, this means that various properties can be specified only once in (2) and need not be repeated on every build, which is clearly a convenient thing.
Anybody has comments about this plan?
Yeah. For a surprisingly large number of *nix users, if the process doesn't look like ./configure && make && make install, they will get upset. That's the reason the configure script was created. Only a small subset of those users may try to set CXXFLAGS et. al, and even a smaller subset needs to do cross-compilation, so I believe we're making more people happy than angry. I would be very, very cautious about removing the configure script. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
on Sat Nov 01 2008, Vladimir Prus <ghost-AT-cs.msu.su> wrote:
As we're nearing 1.37, and the time for big changes that follows after, I wanted to discuss one Boost.Build change I want to make.
Right now, we have two ways to build Boost -- using bjam directly, and using configure and make (which are wrappers over boost.build). The first approach may be a bit hard, and the second is very nice when it works, but it leads to other problems:
- users start to assume it's "real" configure, and get upset when various variables that CXXFLAGS have no effect - if users want to do anything custom, like mingw cross compilation, they have to go back to direct use of bjam anyway.
So, I'd like to suggest a solution where building of boost involves three steps:
1. ./bootstrap.sh or ./bootstrap.bat This step just builds bjam and puts it into boost root
2. ./bjam [--build-type=complete] [--layout=xxx] [properties] configure This step: - Tries to detect what compilers you have - Figures which optional libraries you have, and which you don't (e.g. ICU) - Writes a file project-config.jam with all the discovered information.
3. ./bjam This step can be usually invoked with no parameters, reads the configuration information from project-config.jam, and builds everything.
For new users, this solution is only marginally more complex that configure/make, and does not create the false impression it's autoconf. For power users, the file produced in (2) can be tweaked and extra options can be specified in (3). For all users, this means that various properties can be specified only once in (2) and need not be repeated on every build, which is clearly a convenient thing.
Anybody has comments about this plan?
Yeah. For a surprisingly large number of *nix users, if the process doesn't look like ./configure && make && make install, they will get upset.
I am not so sure -- it is my feeling that any process that, in default case, does not requires to manually specify anything, but just run 1, or 2, or 3 commands, will be fine with most folks.
That's the reason the configure script was created. Only a small subset of those users may try to set CXXFLAGS et. al, and even a smaller subset needs to do cross-compilation, so I believe we're making more people happy than angry. I would be very, very cautious about removing the configure script.
In any case, we can retain the configure script, but make it wrapper over the above scheme, and also change the makefile to be exactly this: all: bjam install: bjam install In this way, if something goes wrong and needs tweaking, I don't have to resort to cumbersome "open Makefile, copy-paste the bjam invocation command, and then..." kind of instructions. - Volodya
on Sun Nov 02 2008, Vladimir Prus <vladimir-AT-codesourcery.com> wrote:
Yeah. For a surprisingly large number of *nix users, if the process doesn't look like ./configure && make && make install, they will get upset.
I am not so sure
This is not just a theory; we have empirical evidence.
-- it is my feeling that any process that, in default case, does not requires to manually specify anything, but just run 1, or 2, or 3 commands, will be fine with most folks.
That's the reason the configure script was created. Only a small subset of those users may try to set CXXFLAGS et. al, and even a smaller subset needs to do cross-compilation, so I believe we're making more people happy than angry. I would be very, very cautious about removing the configure script.
In any case, we can retain the configure script, but make it wrapper over the above scheme, and also change the makefile to be exactly this:
all: bjam install: bjam install
That's fine with me. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
on Sun Nov 02 2008, Vladimir Prus <vladimir-AT-codesourcery.com> wrote:
Yeah. For a surprisingly large number of *nix users, if the process doesn't look like ./configure && make && make install, they will get upset.
I am not so sure
This is not just a theory; we have empirical evidence.
I'm not sure what empirical evidence we have but I can believe it. On the other hand.... I spend a fair amount of time on the boost IRC navigating people away from the ./configure && make method. It isn't like we have users pop onto IRC to explain how well something works... so it may be fine for a large majority. However, we do have a swarm of people after new releases on IRC who cannot get the ./configure && make process to "work". The fastest route to success has repeatedly been to follow the "second method" in the Getting Started guide. The method that describes the bjam command line to execute. I personally haven't tried the ./configure && make process so maybe I should do so. I do field 1 or 2 "can't build boost" problems each day I'm on IRC and typically they involve the ./configure && make process. michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
on Sun Nov 02 2008, Michael Caisse <boost-AT-objectmodelingdesigns.com> wrote:
we do have a swarm of people after new releases on IRC who cannot get the ./configure && make process to "work".
What specific problems are they having? -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
on Sun Nov 02 2008, Michael Caisse <boost-AT-objectmodelingdesigns.com> wrote:
we do have a swarm of people after new releases on IRC who cannot get the ./configure && make process to "work".
What specific problems are they having?
Well, just today: [17:36] <brubelsabs> when I try to compile my program with the -D_GLIBCXX_DEBUG flag, I get errors that some symbols are not found. I've compiled boost by myself via CFLAGS=-D_GLIBCXX_DEBUG and CXXFLAGS=-D_GLIBCXX_DEBUG flag.. can someone guide me what should I try next? [17:36] <brubelsabs> I use regex as well as program_options [17:40] <volodya> brubelsabs: compiled boost yourself via what? [17:43] <brubelsabs> volodya: CXX=g++ CC=gcc CFLAGS=-D_GLIBCXX_DEBUG=1 CXXFLAGS=-D_GLIBCXX_DEBUG=1 ./configure --prefix=/tmp/bd --with-libraries=regex,program_options --with-icu [17:43] <brubelsabs> volodya: that was my configure call [17:44] <volodya> none of these variables have any effect ... [17:48] <volodya> did you think this is autoconf/automake build process? [17:49] <brubelsabs> volodya: yes I thought so Just about every user who wants to do anything else but build with default system gcc gets either to (1) use bjam directly, or (2) try hard to make configure do something, and then use bjam directly. In other words, the statement that folks want "configure; make; make install" is not accurate -- they also assume autoconf + automake. Providing configure actually makes a false impression, and whereas we can counter this impression by making configure produce big warnings that it's not real configure, we can just as well use different name. - Volodya
on Mon Nov 03 2008, Vladimir Prus <vladimir-AT-codesourcery.com> wrote:
In other words, the statement that folks want "configure; make; make install" is not accurate -- they also assume autoconf + automake. Providing configure actually makes a false impression, and whereas we can counter this impression by making configure produce big warnings that it's not real configure, we can just as well use different name.
I find most of your arguments convincing. The only thing I wonder about is discoverability. If you call it configure, *nix people know where to start. If you call it something else, I guess you still have a README.txt and an INSTALL.txt, so maybe it doesn't matter. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Hi, just some comments, I'm a user. Maybe you can make a file configure.txt, or configure-gnu-deprecated.txt non-executable and then when a person runs: ./configure<tab> they come up with that file, and in one it is says: run bjam That would not confuse me. David Abrahams wrote:
on Mon Nov 03 2008, Vladimir Prus <vladimir-AT-codesourcery.com> wrote:
In other words, the statement that folks want "configure; make; make install" is not accurate -- they also assume autoconf + automake. Providing configure actually makes a false impression, and whereas we can counter this impression by making configure produce big warnings that it's not real configure, we can just as well use different name.
I find most of your arguments convincing. The only thing I wonder about is discoverability. If you call it configure, *nix people know where to start. If you call it something else, I guess you still have a README.txt and an INSTALL.txt, so maybe it doesn't matter.
Chris wrote:
Hi, just some comments, I'm a user.
Maybe you can make a file configure.txt, or configure-gnu-deprecated.txt non-executable and then when a person runs: ./configure<tab> they come up with that file, and in one it is says: run bjam That would not confuse me. Tab completion of the first part of the command line doesn't find non-executable files. At least not in a modern bash.
Sebastian
Chris wrote:
Hi, just some comments, I'm a user.
Maybe you can make a file configure.txt, or configure-gnu-deprecated.txt non-executable and then when a person runs: ./configure<tab> they come up with that file, and in one it is says: run bjam That would not confuse me.
Many Linux project have file named INSTALL or INSTALL.txt (I believe GNU project have the as a matter of policy, even). Would that be sufficiently discoverable? - Volodya
I use many libraries, I learned bjam because I use boost in Windows and linux. I use ACE, fltk, and compile many. Overall, I do not fully trust any convention of INSTALL.txt and README.txt. Sometimes they have compilation instructions in README (fltk). Or in ACE-INSTALL.html. Or on the website. Or a text file refers to another source. Or under program option help (cmake openalsoft). If I have a configure, then I don't even read anything. ./configure --help to see options. ./configure, make, sudo make install If not, then I look at any binaries or special files in the directory that tell me what type of build system it uses, or at any text files. I look for "To install, do this: ...". I usually first ignore html files, since I can't vi them. (Sometimes I'm on the console or network.) Vladimir Prus wrote:
Chris wrote:
Hi, just some comments, I'm a user.
Maybe you can make a file configure.txt, or configure-gnu-deprecated.txt non-executable and then when a person runs: ./configure<tab> they come up with that file, and in one it is says: run bjam That would not confuse me.
Many Linux project have file named INSTALL or INSTALL.txt (I believe GNU project have the as a matter of policy, even). Would that be sufficiently discoverable?
- Volodya
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Monday 03 November 2008 13:11:26 Chris wrote:
I use many libraries, I learned bjam because I use boost in Windows and linux. I use ACE, fltk, and compile many. Overall, I do not fully trust any convention of INSTALL.txt and README.txt. Sometimes they have compilation instructions in README (fltk). Or in ACE-INSTALL.html. Or on the website. Or a text file refers to another source. Or under program option help (cmake openalsoft).
If I have a configure, then I don't even read anything. ./configure --help to see options. ./configure, make, sudo make install If not, then I look at any binaries or special files in the directory that tell me what type of build system it uses, or at any text files. I look for "To install, do this: ...". I usually first ignore html files, since I can't vi them. (Sometimes I'm on the console or network.)
I do not understand your point. As a mostly *nix user, here's my take: 1. Most users will use whatever their distribution provides (Linux, OpenSolaris, etc.) and the distribution packagers will figure out that bjam/cmake is what is required. 2. For those that compile from source, the binaries will be installed in some special place, and probably have some complex flags; these users are poorly served by the presence of a configure script that does not exactly match their expectations. In either case, the current configure script does not meet exceptations. Regards, Ravi
Ravi wrote:
On Monday 03 November 2008 13:11:26 Chris wrote:
I use many libraries, I learned bjam because I use boost in Windows and linux. I use ACE, fltk, and compile many. Overall, I do not fully trust any convention of INSTALL.txt and README.txt. Sometimes they have compilation instructions in README (fltk). Or in ACE-INSTALL.html. Or on the website. Or a text file refers to another source. Or under program option help (cmake openalsoft).
If I have a configure, then I don't even read anything. ./configure --help to see options. ./configure, make, sudo make install If not, then I look at any binaries or special files in the directory that tell me what type of build system it uses, or at any text files. I look for "To install, do this: ...". I usually first ignore html files, since I can't vi them. (Sometimes I'm on the console or network.)
I do not understand your point. As a mostly *nix user, here's my take:
I gave my personal process for building anything in general, if boost development wanted to know. The boost configure can be removed for me. If so, my preference is to have a plain text INSTALL.txt file because it's universal (if I don't have a browser).
1. Most users will use whatever their distribution provides (Linux, OpenSolaris, etc.) and the distribution packagers will figure out that bjam/cmake is what is required.
The latest boost for ubuntu intrepid is 1.35. Most of time time I don't bother because they are not the latest. ACE: 5.6.3 (latest is 5.6.6), fltk 1.1 (I use fltk 2).
2. For those that compile from source, the binaries will be installed in some special place, and probably have some complex flags; these users are poorly served by the presence of a configure script that does not exactly match their expectations.
Right, for example I disable python manually because the configure script can't automatically do it. (not fully installed)
On Sun, 2 Nov 2008, David Abrahams wrote:
on Sat Nov 01 2008, Vladimir Prus <ghost-AT-cs.msu.su> wrote:
- users start to assume it's "real" configure, and get upset when various variables that CXXFLAGS have no effect - if users want to do anything custom, like mingw cross compilation, they have to go back to direct use of bjam anyway.
This has bitten me a couple times. You'd be surprised how many people know which flags autoconf needs for a quirky platform.
So, I'd like to suggest a solution where building of boost involves three steps: ... Anybody has comments about this plan?
I like the idea of having a script to compile bjam and copy it to the top directory.
Yeah. For a surprisingly large number of *nix users, if the process doesn't look like ./configure && make && make install, they will get upset. That's the reason the configure script was created.
:) Happy autotools user here.
Only a small subset of those users may try to set CXXFLAGS et. al, and even a smaller subset needs to do cross-compilation, so I believe we're making more people happy than angry. I would be very, very cautious about removing the configure script.
I've had the misfortune of installing boost on several "unusual" boxes (mostly old Sparc/Solaris). I quickly learned to ignore Boost's configure script (had to edit some gcc jam rules). Would it be possible to leave in the configure script and have it print a banner at the end? Something like "" # ./configure ... # compiling bjam, detecting settings, ... Boost configuration complete Configuration summary bjam compiled to path/to/bjam ... # summary of settings To modify these settings, edit user-config.jam. To build, run `make` or bjam --enable-this --disable-that To install, run `make install` or bjam --enable-this --disable-that install "" - Daniel
Vladimir Prus wrote:
As we're nearing 1.37, and the time for big changes that follows after, I wanted to discuss one Boost.Build change I want to make.
[snip]
So, I'd like to suggest a solution where building of boost involves three steps:
1. ./bootstrap.sh or ./bootstrap.bat This step just builds bjam and puts it into boost root
2. ./bjam [--build-type=complete] [--layout=xxx] [properties] configure This step: - Tries to detect what compilers you have - Figures which optional libraries you have, and which you don't (e.g. ICU) - Writes a file project-config.jam with all the discovered information.
3. ./bjam This step can be usually invoked with no parameters, reads the configuration information from project-config.jam, and builds everything.
For new users, this solution is only marginally more complex that configure/make, and does not create the false impression it's autoconf. For power users, the file produced in (2) can be tweaked and extra options can be specified in (3). For all users, this means that various properties can be specified only once in (2) and need not be repeated on every build, which is clearly a convenient thing.
Anybody has comments about this plan?
As long as it also remains possible to build using the same steps as today, it's basically ok. I've been missing a project-config (or equivalent) file for some time. This feature should not only apply to building boost itself, but also when building other projects that use bjam/boost.build as their build system (whether they are actually using boost libraries or not). Some points: - This file should be easily editable by hand, for people who prefers to manually generate/maintain the project-specific configuration. This seems to be covered by your proposal above. - I think it should be possible to specify the name of the project configuration explicitly using command-line arguments, or preferably by using statements in a Jamfile. My main usage scenario for this is that I'd like to be able to maintain project-specific configuration files for different target platforms, storing the configurations in source control together with the code. - It should be possible not to load the project configuration, even if it exists. / Johan
Johan Nilsson wrote:
Vladimir Prus wrote:
As we're nearing 1.37, and the time for big changes that follows after, I wanted to discuss one Boost.Build change I want to make.
[snip]
So, I'd like to suggest a solution where building of boost involves three steps:
1. ./bootstrap.sh or ./bootstrap.bat This step just builds bjam and puts it into boost root
2. ./bjam [--build-type=complete] [--layout=xxx] [properties] configure This step: - Tries to detect what compilers you have - Figures which optional libraries you have, and which you don't (e.g. ICU) - Writes a file project-config.jam with all the discovered information.
3. ./bjam This step can be usually invoked with no parameters, reads the configuration information from project-config.jam, and builds everything.
For new users, this solution is only marginally more complex that configure/make, and does not create the false impression it's autoconf. For power users, the file produced in (2) can be tweaked and extra options can be specified in (3). For all users, this means that various properties can be specified only once in (2) and need not be repeated on every build, which is clearly a convenient thing.
Anybody has comments about this plan?
As long as it also remains possible to build using the same steps as today, it's basically ok.
I've been missing a project-config (or equivalent) file for some time. This feature should not only apply to building boost itself, but also when building other projects that use bjam/boost.build as their build system (whether they are actually using boost libraries or not).
Of course. I plan for this to be totally independent from C++ Boost.
Some points:
- This file should be easily editable by hand, for people who prefers to manually generate/maintain the project-specific configuration. This seems to be covered by your proposal above.
Yes, the file should be basically like user-config.jam, with extra statements to specify build request and any options normally specified on the command line.
- I think it should be possible to specify the name of the project configuration explicitly using command-line arguments, or preferably by using statements in a Jamfile. My main usage scenario for this is that I'd like to be able to maintain project-specific configuration files for different target platforms, storing the configurations in source control together with the code.
- It should be possible not to load the project configuration, even if it exists.
I've noted these points. Thanks, Volodya
On Sat, Nov 1, 2008 at 8:56 AM, Vladimir Prus <ghost@cs.msu.su> wrote:
As we're nearing 1.37, and the time for big changes that follows after, I wanted to discuss one Boost.Build change I want to make.
Right now, we have two ways to build Boost -- using bjam directly, and using configure and make (which are wrappers over boost.build). The first approach may be a bit hard, and the second is very nice when it works, but it leads to other problems:
- users start to assume it's "real" configure, and get upset when various variables that CXXFLAGS have no effect - if users want to do anything custom, like mingw cross compilation, they have to go back to direct use of bjam anyway.
But to me this is more of an indication that the GNU build emulation is not complete more so than configure/make wrappers is somehow inherently flawed. I believe the intent was to make the build more friendly for new comers to the boost world. Its a laudable goal and I think its in boost best interest to make the build as friendly as possible to non-boosters.
So, I'd like to suggest a solution where building of boost involves three steps:
1. ./bootstrap.sh or ./bootstrap.bat This step just builds bjam and puts it into boost root
2. ./bjam [--build-type=complete] [--layout=xxx] [properties] configure This step: - Tries to detect what compilers you have - Figures which optional libraries you have, and which you don't (e.g. ICU) - Writes a file project-config.jam with all the discovered information.
3. ./bjam This step can be usually invoked with no parameters, reads the configuration information from project-config.jam, and builds everything.
For new users, this solution is only marginally more complex that configure/make, and does not create the false impression it's autoconf. For power users, the file produced in (2) can be tweaked and extra options can be specified in (3). For all users, this means that various properties can be specified only once in (2) and need not be repeated on every build, which is clearly a convenient thing.
Even though I think this has some merits, I think the main issues are: - bjam is cryptic to non-boost.build people (even invocation) - step 2 does involve some a priori knowledge of how you want to build which is tricky - build.sh doesn't really build anything, it bootstraps the build tool itself which is again confusing I would say that you would need some kind of option that would allow a list of options and explanations similar to the `configure -help` model otherwise I feel the above has move the barrier to entry a little higher! That's my 2 cents. For the record, I think autoconf and friends are evil evil evil and really are now overkill for most modern build environments (debugging the libtool script can be a life changing experience). But the fact is most build folks and new comers are going to expect some kind of build env that follows the "configure/make/make install" paradigm. I believe for 99% of the builds you can make this work properly but perhaps I'm wrong. I just don't understand why the configure script couldn't be a tad more complete to get what you want? :D -aps
participants (11)
-
Alexander Sack -
Chris -
David Abrahams -
dherring＠ll.mit.edu -
Johan Nilsson -
Michael Caisse -
Ravi -
Robert Ramey -
Sebastian Redl -
Vladimir Prus -
Vladimir Prus