Re: [boost] Need feature branch for compile in-place static linking
Ulrich Eckhardt writes:
Why bother? ------------ The very simple reason is simplicity. * Even on a system where I don't have admin access, I can easily download and compile against Boost, without having to first compile shared/static libs or having to modify paths in order for the runtime linker to find DLLs.
* Even if I had admin access, I would still be reluctant to installing Boost's trunk.
* When I'm testing different compiler settings trying to get another few percent of performance, I don't have to compile another Boost version for each compiler setting.
I think you have to rebuild the compile_inplace.cpp file each time you want to test a different compiler setting. I don't find an advantage to what you advocate here.
* I don't have to know which library to link to, which lowers entry barriers for new Boost users.
* I can easily compile and distribute programs without having to worry about required shared libraries.
That would be helpful. The Ebenezer approach already has that. Brian Wood Ebenezer Enterprises www.webEbenezer.net "Many a time have they afflicted me from my youth, may Israel now say: Many a time have they afflicted me from my youth: yet they have not prevailed against me." Psalm 129: 1,2
* When I'm testing different compiler settings trying to get another few percent of performance, I don't have to compile another Boost version for each compiler setting.
I think you have to rebuild the compile_inplace.cpp file each time you want to test a different compiler setting. I don't find an advantage to what you advocate here.
I think that his approach would be optional, in addition to the existing bjam setup, right? Hopefully those who know how to use a their build tools wont be impacted ;-). Why is branching necessary though? Isn't the proposal just to add a couple new cpp files? will it require modifying the existing ones? -- John
On Wednesday 30 April 2008 01:04:26 John Femiani wrote:
* When I'm testing different compiler settings trying to get another few percent of performance, I don't have to compile another Boost version for each compiler setting.
I think you have to rebuild the compile_inplace.cpp file each time you want to test a different compiler setting. I don't find an advantage to what you advocate here.
I think that his approach would be optional, in addition to the existing bjam setup, right?
Yes.
Why is branching necessary though? Isn't the proposal just to add a couple new cpp files? will it require modifying the existing ones?
There are a few modifications necessary, in particular to get win32 import/export and autolinking right and also some symbol clashes via anonymous namespaces. I already made prototype implementations (it's actually rather easy) both for win32 and Linux, but I haven't tested the exact same code under both OSs. Now, what I'm planning to do first is to branch the current stable version and implement it there. The simple reason is that if something breaks, I can be pretty sure that I broke it. Further, it allows others to check out just those modifications without otherwise downloading the current development trunk. Once I get that ready, I'd merge (or let someone else merge) the changes into the trunk. That's all - the only reason is to keep development a bit separate in order not to break things. Uli
On Wednesday 30 April 2008 00:55:03 brass goowy wrote:
Ulrich Eckhardt writes:
* When I'm testing different compiler settings trying to get another few percent of performance, I don't have to compile another Boost version for each compiler setting.
I think you have to rebuild the compile_inplace.cpp file each time you want to test a different compiler setting. I don't find an advantage to what you advocate here.
The simple advantage is that you don't have to use bjam but you can simply use the buildsystem (if any) you are using for the rest of your project.
* I don't have to know which library to link to, which lowers entry barriers for new Boost users.
* I can easily compile and distribute programs without having to worry about required shared libraries.
That would be helpful. The Ebenezer approach already has that.
What is the 'Ebenezer approach'? Uli
Ulrich Eckhardt wrote:
On Wednesday 30 April 2008 00:55:03 brass goowy wrote:
Ulrich Eckhardt writes:
* When I'm testing different compiler settings trying to get another few percent of performance, I don't have to compile another Boost version for each compiler setting. I think you have to rebuild the compile_inplace.cpp file each time you want to test a different compiler setting. I don't find an advantage to what you advocate here.
The simple advantage is that you don't have to use bjam but you can simply use the buildsystem (if any) you are using for the rest of your project.
How does compiling N source files vs. compiling one source file change wether you need Boost Build or not? Especially since Boost Build is not currently required. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
On Wednesday 30 April 2008 16:52:18 Rene Rivera wrote:
Ulrich Eckhardt wrote:
On Wednesday 30 April 2008 00:55:03 brass goowy wrote:
Ulrich Eckhardt writes:
* When I'm testing different compiler settings trying to get another few percent of performance, I don't have to compile another Boost version for each compiler setting.
I think you have to rebuild the compile_inplace.cpp file each time you want to test a different compiler setting. I don't find an advantage to what you advocate here.
The simple advantage is that you don't have to use bjam but you can simply use the buildsystem (if any) you are using for the rest of your project.
How does compiling N source files vs. compiling one source file change wether you need Boost Build or not? Especially since Boost Build is not currently required.
When I want to use 'proper' libraries (static or shared), I think I either have to use Boost Build or roll my own (I think there are some build files for some IDEs though). First thing I have to find out is which files to compile. Then, I might need some macros set, which may or may not be documented. Further, when upgrading Boost, all this might change, in particular the files to build have changed repeatedly in the past. So, the only thing you need to know is that you need to include <boost/.../compile_in_place.cpp> and you're done. Switching to a new version of Boost or, in the context of the Python support, switching to a different Python version doesn't change anything. That's the simple reason I'm developing this feature. This is just a convenience shortcut for prototyping. It's not a technically superior solution but it is a quick solution. Uli
participants (4)
-
brass goowy -
John Femiani -
Rene Rivera -
Ulrich Eckhardt