version.hpp and 1.34

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

version.hpp and 1.34

Victor A. Wagner Jr.
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"

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: version.hpp and 1.34

Rene Rivera
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: version.hpp and 1.34

Roland Schwarz
In reply to this post by Victor A. Wagner Jr.
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: version.hpp and 1.34

Roland Schwarz
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost