Re: [jamboost] [BBv2]some ideas

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-10-20 02:32:57

Hi pal.tw,

> I add some builtin features which about the
> target-platform property to BBv2.
> It's very simple, and I borrow some code from the
> variant rule.
> Although the value of the 'target-os' feature only
> contains windows-series now.
> Hope it is useful and could be added to the official
> version of BBv2.

I think cross-compiling was mentioned on this list a couple of times. Could 
you give more details about your proposed "target-os" feature. Two questions 
that come to mind
1. shouldn't 'target-os' feature be optional? 
2. It it good idea to define various preprocessor symbols, line _WIN32 and 
UNICODE. Shouldn't the compile take care of this?

> Sometimes I think a few modules of the BBv2 are too
> large to maintain easily.
> So I don't add the code to 'builtin.jam' directly, but
> to another file.
> And merge them together. Maybe in the same way we can
> break some modules
> into smaller ones according to their objectives and
> dependency.
> The naming convention of the files is adopted from the
> suggestion of
> Rational Software Corporation.

Yea, the builtin.jam is really big and should be split. But for splitting it, 
it's ok to use "import". You extra file will work just fine when imported, I 
believe.

> MFC, stlport, boost libraries, and wxWindows -- my
> favorite GUI framework,
> are so popular and common. Maybe The libraries like
> these should be
> configured individually like toolsets but classified
> in another category.

I don't understand what you propose. Separate directory for libraries? Or 
different syntax of library initialization?

> Composite features can be expanded into any other
> features
> including other composite features. But I found the
> composite feature
> would not expand correctly to the exist feature
> <library>.
> Like this...
> ---------------------------------------------------------------------------
>--------- composite target-os : Win95&NT : Win32 :
> <define>WINVER=0x0400 <define>_WIN32_DCOM
> <library>/System//unicows ;
> ---------------------------------------------------------------------------
>--------- So I rewrite that to
> ---------------------------------------------------------------------------
>--------- composite target-os : Win95&NT : Win32 :
> <define>WINVER=0x0400 <define>_WIN32_DCOM
> <library-file>unicows.lib ;
> ---------------------------------------------------------------------------
>---------
>
> Is something wrong within the process of the expansion
> ?

I don't know. Could you send a testcase for me to look at?

> Another issue...
> Basically the new OS will be back-compatiable with the
> old ones as possible.
> The value of 'target-os' is 'Win95' means the program
> or module
> can run in the OS newer than 'Windows 95'.
> It seems that the feature should be link-incompatible,
> but it is not exact.
>
> Because the target with <targe-os>Win98 could link
> with
> the library with <targe-os>Win95 requirment, but the
> target
> with <targe-os>Win95 should not link with the library
> with <targe-os>Win98.
> Or it will make the program not run in Windows 95
> indeed.
>
> Maybe we should consider the relationship of the
> values of the same feature,
> especially they are owned with different targets which
> will be linked together.

The same problem arisen with intel toolset, which, on linux, is 
link-compatible with gcc, so yes, a solution is needed. If you could propose 
one, that would be great. Basically, we need some way to say, 
"<toolset>intel" is compatible with "<toolset>gcc", even if <toolset> is 
link-incompatible. The devil is in the detail -- how to say that.

- Volodya