[1.35] what gets built and installed?

[John Maddock]

If I do a:

bjam stage --toolset=msvc-8.0 --with-regex

Then with 1.35 I don't get any static libraries built, just the dll's.  Was
this a deliberate change somewhere?  It's a problem because the default for
auto-linking is to look for static rather than dynamic libraries.

John.

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

[Rene Rivera-2]

John Maddock wrote:
> If I do a:
>
> bjam stage --toolset=msvc-8.0 --with-regex
>
> Then with 1.35 I don't get any static libraries built, just the dll's.  Was
> this a deliberate change somewhere?  It's a problem because the default for
> auto-linking is to look for static rather than dynamic libraries.

Yes, it was intentional
<http://article.gmane.org/gmane.comp.lib.boost.devel/168552>. We also
discussed it at one point
<http://article.gmane.org/gmane.comp.lib.boost.devel/166847>. I guess we
should switch autolink to default to the dynamic libs?


--
-- 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-build

[Jurko Gospodnetić]

   Hi Rene.

   Is there a simple way to 'build all variants' as was previously done
by default? The original thread mentioned some kind of a 'build all'
command line option.

   Also, as I said in the original thread, if this 'build all' command
line option gets implemented then it would be useful to update the
documentation with an example of how such things are done in Boost Build
for other Boost Build projects.

   Thanks.

   Best regards,
    Jurko Gospodnetić

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

[John Maddock]

Rene Rivera wrote:

> John Maddock wrote:
>> If I do a:
>>
>> bjam stage --toolset=msvc-8.0 --with-regex
>>
>> Then with 1.35 I don't get any static libraries built, just the
>> dll's.  Was this a deliberate change somewhere?  It's a problem
>> because the default for auto-linking is to look for static rather
>> than dynamic libraries.
>
> Yes, it was intentional
> <http://article.gmane.org/gmane.comp.lib.boost.devel/168552>. We also
> discussed it at one point
> <http://article.gmane.org/gmane.comp.lib.boost.devel/166847>. I guess
> we
> should switch autolink to default to the dynamic libs?

That's actually not possible without changing folks library code: it's a
per-library decision which is the default, with the static library being
recomended as the default unless there are reasons to choose otherwise.
There's a great deal of documentation that would have to change to reflect
this as well.

There's also a rationale for why static linking is the default behaviour in
our docs here:
http://www.boost.org/more/separate_compilation.html#static_or_dynamic

There's a further issue with building only one variant under MSVC: it
doesn't work!

By only building a release build, then the only thing that will work
"straight out the box" is building a release build of your application
against the dll runtime.  Debug builds will generate linker errors (can't
find the auto-linked library etc), as will builds against the static
runtime, this means that Boost will appear totally broken if users try and
build the default debug builds that their IDE gives them.

We need to be *very* careful with this, or the complaints will be loud and
vociferous!

If the aim is to reduce the number of variants built, then I would suggest:

Dymanic *and* static lib, as Release, multithreaded, dynamic runtime single
build on Unix variants (2 build variants).
Dynamic *and* static lib, Release *and* Debug, multithreaded, dynamic
runtime on Win32 compilers (that's 4 build variants).

That's an absolute minimum IMO.  Even then we will have to be very careful
that our build instructions indicate very clearly how to build the other
variants, especially for those msvc users :-)

Sorry to be the bearer of the bad news,

John.

PS this is too important and far reaching to be discussed only on
boost-build IMO.

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

[Vladimir Prus]

John Maddock wrote:

> Rene Rivera wrote:
>> John Maddock wrote:
>>> If I do a:
>>>
>>> bjam stage --toolset=msvc-8.0 --with-regex
>>>
>>> Then with 1.35 I don't get any static libraries built, just the
>>> dll's.  Was this a deliberate change somewhere?  It's a problem
>>> because the default for auto-linking is to look for static rather
>>> than dynamic libraries.
>>
>> Yes, it was intentional
>> <http://article.gmane.org/gmane.comp.lib.boost.devel/168552>. We also
>> discussed it at one point
>> <http://article.gmane.org/gmane.comp.lib.boost.devel/166847>. I guess
>> we
>> should switch autolink to default to the dynamic libs?
>
> That's actually not possible without changing folks library code: it's a
> per-library decision which is the default, with the static library being
> recomended as the default unless there are reasons to choose otherwise.
> There's a great deal of documentation that would have to change to reflect
> this as well.
>
> There's also a rationale for why static linking is the default behaviour
> in our docs here:
> http://www.boost.org/more/separate_compilation.html#static_or_dynamic
>
> There's a further issue with building only one variant under MSVC: it
> doesn't work!
>
> By only building a release build, then the only thing that will work
> "straight out the box" is building a release build of your application
> against the dll runtime.  Debug builds will generate linker errors (can't
> find the auto-linked library etc), as will builds against the static
> runtime, this means that Boost will appear totally broken if users try and
> build the default debug builds that their IDE gives them.
>
> We need to be *very* careful with this, or the complaints will be loud and
> vociferous!
> If the aim is to reduce the number of variants built, then I would
> suggest:
>
> Dymanic *and* static lib, as Release, multithreaded, dynamic runtime
> single build on Unix variants (2 build variants).

I'd be opposed to this. How many popular projects can you name,
that build two variants on Linux?

- Volodya


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

[Rush Manbert]

John Maddock wrote:

> Rene Rivera wrote:
>
>>John Maddock wrote:
>>
>>>If I do a:
>>>
>>>bjam stage --toolset=msvc-8.0 --with-regex
>>>
>>>Then with 1.35 I don't get any static libraries built, just the
>>>dll's.  Was this a deliberate change somewhere?  It's a problem
>>>because the default for auto-linking is to look for static rather
>>>than dynamic libraries.
>>
>>Yes, it was intentional
>><http://article.gmane.org/gmane.comp.lib.boost.devel/168552>. We also
>>discussed it at one point
>><http://article.gmane.org/gmane.comp.lib.boost.devel/166847>. I guess
>>we
>>should switch autolink to default to the dynamic libs?
>
>
> That's actually not possible without changing folks library code: it's a
> per-library decision which is the default, with the static library being
> recomended as the default unless there are reasons to choose otherwise.
> There's a great deal of documentation that would have to change to reflect
> this as well.
>
> There's also a rationale for why static linking is the default behaviour in
> our docs here:
> http://www.boost.org/more/separate_compilation.html#static_or_dynamic
>
> There's a further issue with building only one variant under MSVC: it
> doesn't work!
>
> By only building a release build, then the only thing that will work
> "straight out the box" is building a release build of your application
> against the dll runtime.  Debug builds will generate linker errors (can't
> find the auto-linked library etc), as will builds against the static
> runtime, this means that Boost will appear totally broken if users try and
> build the default debug builds that their IDE gives them.
>
> We need to be *very* careful with this, or the complaints will be loud and
> vociferous!
>
> If the aim is to reduce the number of variants built, then I would suggest:
>
> Dymanic *and* static lib, as Release, multithreaded, dynamic runtime single
> build on Unix variants (2 build variants).
> Dynamic *and* static lib, Release *and* Debug, multithreaded, dynamic
> runtime on Win32 compilers (that's 4 build variants).
>
> That's an absolute minimum IMO.  Even then we will have to be very careful
> that our build instructions indicate very clearly how to build the other
> variants, especially for those msvc users :-)
>
> Sorry to be the bearer of the bad news,
>
> John.
>
> PS this is too important and far reaching to be discussed only on
> boost-build IMO.

If a user may be permitted to comment, I think John is correct here. It
is far better that the boost build take a long time (with a big warning
in the build instructions to that effect) but build all of the normally
used variants than having it build only Release shared libraries.

I would venture to guess that most Boost users are developing for
deployment to their users, and many of them will want to be statically
linked to Boost in order to avoid a whole host of issues. I also can't
believe that anyone who uses an IDE for development doesn't build Debug
versions much more often, and usually by default, than they build
Release versions. This is certainly true for MSVC and Xcode users.

I think you will get many complaints and spend a lot of time answering
the "how do I build static libraries on platform x" posts if you change
the default.

Best regards,
Rush
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

[Felipe Magno de Almeida]

On Dec 19, 2007 3:19 PM, Vladimir Prus <ghost@...> wrote:
>

[snip]

> >
> > Dymanic *and* static lib, as Release, multithreaded, dynamic runtime
> > single build on Unix variants (2 build variants).
>
> I'd be opposed to this. How many popular projects can you name,
> that build two variants on Linux?

That build two I don't know, but for most libraries one have to
download two packets to develop with it.
gtk+ and gtk+-dev, etc.
I would prefer to have release and debug variants instead of dynamic and static.
But then it seems like an argument to have just one variant.
AFAIK, people usually download boost to develop with it, not as a
binary dependency for some other project.

>
> - Volodya


--
Felipe Magno de Almeida
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

[Rene Rivera-2]

Jurko Gospodnetic' wrote:
>    Hi Rene.
>
>    Is there a simple way to 'build all variants' as was previously done
> by default? The original thread mentioned some kind of a 'build all'
> command line option.

Yes, as mentioned in the --help blurb, there's a --build-type=complete
option.

>    Also, as I said in the original thread, if this 'build all' command
> line option gets implemented then it would be useful to update the
> documentation with an example of how such things are done in Boost Build
> for other Boost Build projects.

All I did was change what the "default build" is in the top level
project Jamroot.


--
-- 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-build

[Rush Manbert]

John Maddock wrote:

> Rene Rivera wrote:
>
>>John Maddock wrote:
>>
>>>If I do a:
>>>
>>>bjam stage --toolset=msvc-8.0 --with-regex
>>>
>>>Then with 1.35 I don't get any static libraries built, just the
>>>dll's.  Was this a deliberate change somewhere?  It's a problem
>>>because the default for auto-linking is to look for static rather
>>>than dynamic libraries.
>>
>>Yes, it was intentional
>><http://article.gmane.org/gmane.comp.lib.boost.devel/168552>. We also
>>discussed it at one point
>><http://article.gmane.org/gmane.comp.lib.boost.devel/166847>. I guess
>>we
>>should switch autolink to default to the dynamic libs?
>
>
> That's actually not possible without changing folks library code: it's a
> per-library decision which is the default, with the static library being
> recomended as the default unless there are reasons to choose otherwise.
> There's a great deal of documentation that would have to change to reflect
> this as well.
>
> There's also a rationale for why static linking is the default behaviour in
> our docs here:
> http://www.boost.org/more/separate_compilation.html#static_or_dynamic
>
> There's a further issue with building only one variant under MSVC: it
> doesn't work!
>
> By only building a release build, then the only thing that will work
> "straight out the box" is building a release build of your application
> against the dll runtime.  Debug builds will generate linker errors (can't
> find the auto-linked library etc), as will builds against the static
> runtime, this means that Boost will appear totally broken if users try and
> build the default debug builds that their IDE gives them.
>
> We need to be *very* careful with this, or the complaints will be loud and
> vociferous!
>
> If the aim is to reduce the number of variants built, then I would suggest:
>
> Dymanic *and* static lib, as Release, multithreaded, dynamic runtime single
> build on Unix variants (2 build variants).
> Dynamic *and* static lib, Release *and* Debug, multithreaded, dynamic
> runtime on Win32 compilers (that's 4 build variants).
>
> That's an absolute minimum IMO.  Even then we will have to be very careful
> that our build instructions indicate very clearly how to build the other
> variants, especially for those msvc users :-)
>
> Sorry to be the bearer of the bad news,
>

If a user may be permitted to comment, I think John is correct here. It
is far better that the boost build take a long time (with a big warning
in the build instructions to that effect) but build all of the normally
used variants than having it build only Release shared libraries.

My guess is that most Boost users are developing for deployment to their
users, and many of them will want their apps to be statically linked to
Boost libraries, among others, in order to avoid a whole host of issues.
I also can't believe that anyone who uses an IDE for development doesn't
build Debug versions much more often, and usually by default, than they
build Release versions. This is certainly true for MSVC and Xcode users.

I think you will get many complaints and spend a lot of time answering
the "how do I build static libraries on platform x" and "how do I build
debug libraries" posts if you change the default. If you do change the
default behavior to build only Release shared libraries, then you need
to make it dead simple to build all of the variants.

Best regards,
Rush
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

[John Maddock]

Vladimir Prus wrote:
> I'd be opposed to this. How many popular projects can you name,
> that build two variants on Linux?

Every single one that uses libtool: so most of them then :-)

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