Boost logo

Boost-Build :

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2004-11-20 07:48:52

Vladimir Prus wrote:
> Hi Reece,
>>>Your Jamfiles would have conditions for all supportest OSes:
>>> lib gui : .......... : <os>NT:<define>FOO <os>palmos:<define>BAR ;
>>>The only problem I see if that we need to adjust the tools so that they
>>>understand the <os> feature.
>>The <os> feature is currently builtin and defined to the OS that is
>>running (e.g. cygwin, linux, NT). Maybe this could be <target-os>, which
>>would allow you to leave <os> as the "host" operating system and
>><target-os> as the os being compiled to.
>>E.g. bjam cw-8.3 target-os=mac # os=NT
> Why would you want to have host os as property? After all, you can't build
> with two host os at the moment. In other words
> bjam cw-8.3 host-os=NT host-os=LINUX
> makes no sense, so Boost.Build can just detect host os itself and use this
> information when needed. And that means "os" can mean "target os".

What I mean is that bjam defines os to be the OS that the user is
running on (i.e. the host os). This is set internally, so you don't set
it on the command line (thst is not what I meant).

>>One of the motivations for using <gui> as a feature, or a better name
>>might be <os-api>, is to allow support for different APIs, e.g.:
>> bjam msvc-8.0 os-api=win32
>> bjam msvc-8.0 os-api=win64
>> bjam gcc-3.3 target-os=linux os-api=x11
>> bjam gcc-3.3 target-os=linux os-api=motif
> Maybe you're right, if you want to target Qt and gtk, then <os> would be too
> coarse grained.

We can have the following rules:
[1] set <os> to the operating system being run (already implemented);
[2] if <target-os> is not defined, define it to be equal to <os> (note:
you may want to define <target-os> as NT when <os>=CYGWIN).
[3] validate that <target-os> has an appropriate value (already
provided via feature).
[4] if <os-api> is not defined, define it to an appropriate default (e.g.:
[5] validate that the <os-api> value is appropriate for the value of
<target-os> (e.g. <target-os>LINUX:<os-api>cocoa is invalid).

>>>>SIDE NOTE: When I compile a GUI application (<user-interface>gui) in gcc
>>>>using bjam, I get a console window as well as the GUI frame. Is there a
>>>>way to remove the console window in this configuration?
>>>I don't know. Do you have WinMain as entry point?
>>The WinMain entry point is implemented in lib gui. Maybe, if I add an
>>extern WinMain to the header included by the application it may work.
> I'm afraid I don't have any further ideas. It's being awhile since I wrote any
> GUI code for windows.

I will look into it at some point. Thanks, anyway.



Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at