Re: [jamboost] Plans?

From: Rene Rivera (grafik666_at_[hidden])
Date: 2002-12-11 01:08:23

[2002-12-10] David Abrahams wrote:

>Vladimir Prus <ghost_at_[hidden]> writes:
>
>> Gentlemen,
>> can we discuss our current situation and short-term plans?
>>
>> As I recall, Rene was going to implement sonames on gcc and better
>> stage target (with relinking) -- BB9. Rene, did you get anywhere?

I did some poking around to figure out how to make use of the symlink target
to do the work. But it requires some changes to targets, which I'll post
about later this week.

>> He also proposed the "source" rule (BB12), which I find quite important
now.
>> Rene, if you're pressed for time, maybe you could do this one first.
After
>> symlink that you've implemented, this would be extra easy. (Still, maybe
>> it should be caled "alias"?)
>
>I think we agreed on "alias" didn't we?

No. I was in favor of "source", for various reasons. But I'm not too stuck
on the name ;-) ... I can live with "alias".

>> Speaking about my plans, there is some polishing:
>> 1. I'd like to hardcode dll paths in debug builds. Should be easy, except
>> for learning the right way to do it.
>
>I don't think we want to do that unconditionally. Lots of people like
>to install debug builds, for whatever reason. I also think we won't
>be able to escape the need to set up the environment properly for
>testing from withing Boost.Build -- e.g. people might want to test
>release builds that way, or they might need PYTHONPATH set, or...
>
>So I'm not completely sure it's worth investing in this.

I tend to agree with that. I personally would just like to see the
<dll-path> (or whatever it's called) feature added. And then it would be up
to us to use it accordingly in projects.

>> 2. Allow single build directory at project root (BB7)
>
>Or anywhere else, I hope!
>
>> 3. BB14 -- toolset specific suffixes. This should allow to use "so"
>> on NT/gcc and "dll" on NT/borland, at the same time.
>
>I think we clarified that NT always requires "dll".
>However, Python extensions can be called "pyd" as long as we're not
>using cygwin Python.

For this I would like to see a generic variable-value selection mechanism.
I'm not sure how it works now (I'll look briefly tomorrow), but setting and
getting "arbitrary" variables based on combinations of platform, toolset,
feature+value, feature, and the inverses of all those is something that
would make writting toolsets much easier.

>> There are two more issues. BB5 is the "using" rule, and toolset
configuration. 
>> Seems like it's quite simple and almost finished. I'll implement stlport
>> support soon to make sure.
>>
>> BB6 is toolset implementation.
>> There's gcc support and preliminary borland support. Unfortunately, I
don't 
>> understand some parts of current gcc-tools.jam, so
>> can't do anything about it. We'd probably want MSVC support too, ASAP,
but
>> I have no clue about import libraries, PCH, PDB, and it fact, don't have
>> that compiler.
>>
>> Dave, Rene, I really hope for your assistance here.
>
>I'd be pleased to help. Right now I'm just trying to get started
>writing a CUJ article on Boost.Python. I should be able to mix in
>some BBv2 work.

I'm somewhat busy, but I can spend some time on this. Can't help on MSVC,
but I can certainly decipher the current GCC toolset for you if needed.

-- grafik - Don't Assume Anything
-- rrivera_at_[hidden] - grafik_at_[hidden]
-- 102708583_at_icq