Has something changed in the way you build libraries? I'm building using the following command: bjam --build-dir=builddir --toolset=msvc-8.0 stage This no longer builds any of the libboost* versions, nor any debug builds when run against 1.35. bjam version is 03.1.16. I'm not having any issues with gcc builds. Secondly, is there a link on the website to the 1.35 Getting Started docs? I ended up finding it through the searc on the site. It might be nice if that was linked to from the documentation section. Maybe even listed at the top. Thanks, Jared
Jared McIntyre wrote:
Has something changed in the way you build libraries? I'm building using the following command:
bjam --build-dir=builddir --toolset=msvc-8.0 stage
You need to pass --build-type=complete like: bjam --build-dir=builddir --build-type-complete --toolset=msvc-8.0 stage Regards, Cristi.
On Mon, Mar 31, 2008 at 07:33:35AM +0200, Cristian Adam wrote:
Jared McIntyre wrote:
Has something changed in the way you build libraries?
You need to pass --build-type=complete like:
The build-type option has been in the trunk for a long while but wasn't merged to the 1.35.0 release candidates until the last one of them. By default, it's set to minimal which will only build dynamic release libraries. If set to complete, it will build everything like it used to. -- Lars Viklund | zao@acc.umu.se | 070-310 47 07
It would be great to have all possibilities that go after --build-type=xxxxxxxxxx Regards, F. Bron
You need to pass --build-type=complete like:
Avis : Ce message et toute pièce jointe sont la propriété d'Alcan et sont destinés seulement aux personnes ou à l'entité à qui le message est adressé. Si vous avez reçu ce message par erreur, veuillez le détruire et en aviser l'expéditeur par courriel. Si vous n'êtes pas le destinataire du message, vous n'êtes pas autorisé à utiliser, à copier ou à divulguer le contenu du message ou ses pièces jointes en tout ou en partie. Notice: This message and any attachments are the property of Alcan and are intended solely for the named recipients or entity to whom this message is addressed. If you have received this message in error please inform the sender via e-mail and destroy the message. If you are not the intended recipient you are not allowed to use, copy or disclose the contents or attachments in whole or in part.
On Mon, Mar 31, 2008 at 11:17:50AM +0200, frederic.bron@alcan.com wrote:
It would be great to have all possibilities that go after --build-type=xxxxxxxxxx
As 'bjam --help' so friendly explains: --build-type=<type> Build the specified pre-defined set of variations of the libraries. Note, that which variants get built depends on what each library supports. minimal (default) - Builds the single "release" version of the libraries. This release corresponds to specifying: "release <threading>multi <link>shared <runtime-link>shared" as the Boost.Build variant to build. complete - Attempts to build all possible variations. -- Lars Viklund | zao@acc.umu.se | 070-310 47 07
Lars Viklund <zao <at> acc.umu.se> writes:
On Mon, Mar 31, 2008 at 07:33:35AM +0200, Cristian Adam wrote:
Jared McIntyre wrote:
Has something changed in the way you build libraries?
You need to pass --build-type=complete like:
The build-type option has been in the trunk for a long while but wasn't merged to the 1.35.0 release candidates until the last one of them. By default, it's set to minimal which will only build dynamic release libraries. If set to complete, it will build everything like it used to.
This is probably important to clarify in the Getting Started documentation. This is especially true because the headers still include the libboost* version by default in Visual Studio builds, and debug versions of those if you are building debug. None of these are built if you follow the steps in the Getting Started document. So, by default, following that doc won't get you a usable setup.
This is probably important to clarify in the Getting Started documentation. This is especially true because the headers still include the libboost* version by default in Visual Studio builds, and debug versions of those if you are building debug. None of these are built if you follow the steps in the Getting Started document. So, by default, following that doc won't get you a usable setup.
I've got ticket #1720 open on this issue. My description is clouded by the fact that I'm learning to use bjam / boost.build by trial and error in the process. For the next couple of years anyone doing commercial software on Windows is going to need 32- and 64-bit builds side-by-side. I will either provide updated "Getting Started on Windows" language or collaborate with anyone else working toward the same goal. But I think we need to get some better language onto the web site muy pronto. It's taken me a week and several round-trips through the list to get it mostly working, and it was all due to "beginner hostile" documentation.
Jared McIntyre wrote:
Lars Viklund <zao <at> acc.umu.se> writes:
On Mon, Mar 31, 2008 at 07:33:35AM +0200, Cristian Adam wrote:
Jared McIntyre wrote:
Has something changed in the way you build libraries? You need to pass --build-type=complete like:
The build-type option has been in the trunk for a long while but wasn't merged to the 1.35.0 release candidates until the last one of them. By default, it's set to minimal which will only build dynamic release libraries. If set to complete, it will build everything like it used to.
This is probably important to clarify in the Getting Started documentation. This is especially true because the headers still include the libboost* version by default in Visual Studio builds, and debug versions of those if you are building debug. None of these are built if you follow the steps in the Getting Started document. So, by default, following that doc won't get you a usable setup.+
I suggested a while back on the Boost Build NG that the default should be all libraries built while other options to build a subset of the libraries should be documented but it was rejected for the current way. I knew that people would be confused by doing their build, as always, and not seeing the libraries which had preciously always been built, not generated.
Edward Diener <eldiener <at> tropicsoft.com> writes:
I suggested a while back on the Boost Build NG that the default should be all libraries built while other options to build a subset of the libraries should be documented but it was rejected for the current way. I knew that people would be confused by doing their build, as always, and not seeing the libraries which had preciously always been built, not generated.
I'm used to the build process changing (at least slightly) in a full release, so I always check Getting Started to see what the new way to build is now. But now if you follow the steps in that document, your code won't actually work as described. For example, it tells you to include regex.hpp and that will auto-link to the regex library, except that it auto-links to the libboost version of regex which isn't built using the instruction on how to build earlier in the document. Similarly, it talks about manually linking to libboost_regex-vc71-mt-d-1_34.lib, which also wouldn't exist (and not just because it refers to 1_34). It seems that the default build should at least build the libraries that the auto-link will link to, otherwise you have to build it differently to use auto-link. By the way, this is the page I'm referring to, since it doesn't seem to have an obvious link on the site anymore: http://www.boost.org/doc/libs/1_35_0/more/getting_started/windows.html Of course, maybe this is why it doesn't have that link... Jared
Edward Diener wrote:
I suggested a while back on the Boost Build NG that the default should be all libraries built while other options to build a subset of the libraries should be documented but it was rejected for the current way. I knew that people would be confused by doing their build, as always, and not seeing the libraries which had preciously always been built, not generated.
Ditto :-( John.
On 01/04/2008, Jurko Gospodnetić <jurko.gospodnetic@docte.hr> wrote:
Hi.
I knew that people would be confused by doing their build, as always, and not seeing the libraries which had preciously always been built, not generated.
I second that...
Best regards,
Jurko Gospodnetić
I'll third that - as it stands, #include'ing boost/regex.hpp leads to code that won't build under Debug and Release in VS 2003+ - that sucks. If the default Boost build script is only going to builds one variant of the libraries, then at least the 'Getting Started' material should mention pretty clearly how to build the rest. Not everyone'll be able to craft an appropriate Google query like I did :-) Stuart Dootson
Hi all, I've been busy with porting the public domain C library libtommath to C++. The code is quite usable as it is and some simple documentation exists in the libs/mp_math/doc/html subfolder. I've implemented all C++ operators for the mp_int<> type and it can thus be used just like a built-in integer type. Some things like random number generation and primality testing have not been documented yet. Please have a look, I'm looking for feedback at the moment so that I can plan on how to proceed. 2008/3/31, Jared McIntyre <jmcintyre@dfsoftware.com>:
Has something changed in the way you build libraries? I'm building using the following command:
bjam --build-dir=builddir --toolset=msvc-8.0 stage
This no longer builds any of the libboost* versions, nor any debug builds when run against 1.35. bjam version is 03.1.16. I'm not having any issues with gcc builds.
Secondly, is there a link on the website to the 1.35 Getting Started docs? I ended up finding it through the searc on the site. It might be nice if that was linked to from the documentation section. Maybe even listed at the top.
Thanks,
Jared
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- In god we trust. Thierno Camara
participants (10)
-
Cristian Adam -
Edward Diener -
frederic.bron＠alcan.com -
Jared McIntyre -
John Maddock -
Jurko Gospodnetić -
Lars Viklund -
Stephen Nuchia -
Stuart Dootson -
thierno camara