Re: Plans?

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-12-11 04:01:48

Rene Rivera wrote:

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

I'm looking forward.

>>> 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".

OK, there's +1 on "alias" from Markus, Dave (if I got him right) and myself.
Gonna use it.

>>> Speaking about my plans, there is some polishing:
>>> 1. I'd like to hardcode dll paths in debug builds. Should be easy,
>>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.

As I've said in another message, you can't accomplish that with <dll-path> 
alone.

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

You're right -- we'd propably need to separate this logic. An important
thing that you mention is "inverses of all those". I'd like that. I probably
would like handling absense of features, too. E.g. to set gcc name to 
something when no <toolset-option> is specified.

- Volodya

> 
>>> 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
> 
> 
> To unsubscribe from this group, send an email to:
> jamboost-unsubscribe_at_[hidden]
> 
> 
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

-- 
Regards,
Vladimir