I notice that version.hpp in both head and rc1_34_0 is the same this causes me many problems I further note that the install seems to name the resulting .lib and .dll files w/ 1_34 NOT 1_34_0 and I don't see where to change that for some reason I'm getting buffer overrruns in cl.exe (vc7.1) when doing V2 runs I've stopped doing cvs-head runs because of the filename collisions btw, the revision encoding mechanism that's currently in use will cause problems in the future, there's no way to tell the difference between 1_34_0 (103400) and 1_34 whch apparently also will encode to 103400 Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
Victor A. Wagner Jr. wrote:
I notice that version.hpp in both head and rc1_34_0 is the same this causes me many problems
Good question. Is there something in the release manager checklist for when and if to change the version number of head?
I further note that the install seems to name the resulting .lib and .dll files w/ 1_34 NOT 1_34_0 and I don't see where to change that
AFAIK it's supposed to be that way. For 1.34.0 it should use 1_34, and for 1.34.1 it should use 1_34_1 if we ever have one of those that is. It was done this way for 1.33.0 and 1.33.1 because we overlooked the binary incompatibility ramifications only after 1.33.0 was out.
I've stopped doing cvs-head runs because of the filename collisions
I would think you would do such testing runs to/from different locations.
btw, the revision encoding mechanism that's currently in use will cause problems in the future, there's no way to tell the difference between 1_34_0 (103400) and 1_34 whch apparently also will encode to 103400
There's never going to be a 1_34_0. If I understand you quandry correctly. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Victor A. Wagner Jr. wrote:
I notice that version.hpp in both head and rc1_34_0 is the same this causes me many problems
I further note that the install seems to name the resulting .lib and .dll files w/ 1_34 NOT 1_34_0 and I don't see where to change that
for some reason I'm getting buffer overrruns in cl.exe (vc7.1) when doing V2 runs
I've stopped doing cvs-head runs because of the filename collisions
I solve this by giving the bjam option --layout=system for HEAD installs and --layout=versioned for the release branches. Roland
Roland Schwarz wrote:
I solve this by giving the bjam option --layout=system for HEAD installs and --layout=versioned for the release branches.
Al tough I was using this , I just discovered that it only worked by accident. What is missing, so this really will work, at least on windows with autolink, is something of a macro BOOST_LAYOUT which complements the Boost.Build --layout= command line option. I would consider this even as a bug since on windows when building with --layout=system the autolink feature is not working at all. BOOST_AUTO_LINK_NOMANGLE is not of help here, since the --layout=system still applies lib prefix and threading and runtime suffixes. In an ideal world, when doing bjam --layout=system install, the header file boost/config/autolink.hpp would be patched with the correct setting of the proposed BOOST_LAYOUT macro. But then --layout=system might not be intended for win32. It should be disabled then for windows? What do you think? Roland
participants (3)
-
Rene Rivera -
Roland Schwarz -
Victor A. Wagner Jr.