On Fri, Jun 01, 2012 at 08:06:30AM -0400, Nat Linden wrote:

On Fri, Jun 1, 2012 at 7:35 AM, Martin Elzen wrote:

...

Ohad Barta wrote:

...

...

what is the corresponding cmd compilation command? I tried to specify all the corresponding flags but for some reason it doesn't work,(for example- despite using the flag --address-model=64, the folder "address-model-64" wasn't constructed in my folders hierarchy tree, so I guess that this flag was ignored)

...

There may be other errors, but what jumps out at me right now is that the "address-model=" part does NOT require two minus-signs in front of it...

What would be the drawback to supporting all such switches in both syntaxes? (address-model= or --address-model=)

The set of options are rather fixed and domain-unspecific. The set of features isn't and are up to the particular things you're trying to build. Mixing the two together is a dangerous, incomplete and completely wrong thing to do. Users should take care in understanding the command line tool they use, and stop assuming that it behaves according to some particular GNU-like environment they are familiar with. GCC multicharacter flags start with a single dash. Windows parameters start with a /. You don't see applications changing to handle those worldviews. -- Lars Viklund | zao@acc.umu.se

On Fri, Jun 01, 2012 at 09:44:24AM -0400, Nat Linden wrote:

But I'll drop this because I'd forgotten that CMake is going to make all the above moot.

I look forward to seeing how (I assume they _will_) the CMake efforts handle all the variants that Boost provides/allows, and the abysmal syntax they will invent to make it happen. I mean, there's not much of a difference between: * b2 toolset=msvc-11.0 --prefix=C:\Boost address-model=64 and * cmake -G "Visual Studio 2012 Win64 Solution" -DCMAKE_INSTALL_PREFIX:STRING=C:\Boost Except of course that the former is extensible, homoegeneous, and doesn't have all that weirdo string cache shenanigans and requiring fresh build directories and manual cleanout of artifacts if you're ever insane enough to do in-tree builds. I also look forward to the Sisyphusean struggle to support ancient versions of CMake vs. actually being able to express things in your build scripts. Boost.Build has a gigantic advantage in being trivially bundlable with the Boost archive and trivially buildable on anything that has a C compiler. CMake is a quite more serious dependency and the binaries provided are small in number and in the case of AIX, doesn't even run due to the instruction set supported by some machines. Silly as it may be, we have signficant competence in Boost.Build and it does what it should excellently. CMake will not make anything moot. It will just make it different. Users are still broken, and they will still need assistance and documentation. The difference is that no-one that pushes the CMake effort will be around to aid them, and no-one will be arsed to grok the build system beyond the bare minimum they need to get their things working. Don't underestimate the rather hidden amount of support that is being done outside of the lists. -- Lars Viklund | zao@acc.umu.se