|
|
Boost-Build : |
From: pal.tw (pal.tw_at_[hidden])
Date: 2003-10-21 03:05:38
--0-204284882-1066723538=:67909 Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 8bit
--- In jamboost_at_[hidden], Vladimir Prus <ghost_at_c...> wrote:
> 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?
>
1. I guess you think it should be optional. Because in general,
the development environment is the same as the execution
environment of programs. But I think 'target-os' should be
set in default to the value of 'host-os'. That's why I add
'HOST_OS' built-in variable in Bjam. In Windows World,
we usually develop the programs for one OS in different OS.
For example, I often write a program for Windows 9x
in Windows 2000.
Of course, cross-compiling is another advanced issue.
I image that the script of BBv2 will explain the
relationship between the values of 'target-os' and 'host-os',
and then transform this into the actions and the arguments which
the compiler or the linker need. If 'target-os' and 'host-os'
are the same, maybe BBv2 just pass through and do nothing.
In addition, it may restrict the choice of toolsets, and
pick up or detect the most popular one for builder
when they doesn't choose one.
I know the codes I provide is not perfect, but it is just
beginning, not the end. Any opinions or ideas will be fine.
Maybe we can make it better and better together.
2. Mmmm.... The conditional compilations are involved with
Microsoft Platform SDK, not just for an individual toolset,
MSVC, BCB/BCC, or mingw...etc.
No matter what toolset we use, if the programs want to use
the services which the Windows provide, they must include
the header files Microsoft provides. It imply that you must
follow the conditional compilation rules they made.
Many APIs of the NT-series platform are implemented as
Unicode and ANSI versions in order to compatible with
the Win9x-series. The 'UNICODE' symbol just tells
compiler to use the Unicode version. It seems that
the Win9x-series will be obsolete, and Microsoft provides
MSLU (Microsoft Layer for Unicode on Windows 95/98/Me Systems).
So there is no reason why not use the Unicode version of APIs
from now on.
But apply 'UNICODE' to all Win32 platform is certainly wrong.
Therefor I fix it already.
>
> 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.
>
"import" will work. but what I want to show is to divide
a 'module' into serveral files. As before, a 'module' must
in a single file, it will become larger and larger
in the process of development. If we can split it,
maybe it can be split into the stable codes and the draft ones first.
> I don't understand what you propose. Separate directory for libraries? Or
> different syntax of library initialization?
>
Yes, that's what I mean. Separate directory and
perhaps different syntax of library initialization.
> > Is something wrong within the process of the expansion
> > ?
>
> I don't know. Could you send a testcase for me to look at?
>
I made a sample. You can use your library and unmark the line
which invokes 'feature.compose' rule. The result is so strange...
> 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.
>
okay, I will express my idea in detail in this weekend.
- Paul Lin
---------------------------------
¨C¤Ñ³£ Yahoo!©_¼¯
®üªºÃC¦â¡B·ªº®ð®§¡B·R§Aªº·Å«×¡AºÉ¦b«H¯È©³¹Ï
«H¯È©³¹Ï --0-204284882-1066723538=:67909 Content-Type: text/html; charset=big5
Content-Transfer-Encoding: 8bit
<DIV>
<P>--- In <A href="mailto:jamboost_at_[hidden]">jamboost_at_[hidden]</A>, Vladimir Prus <<A href="mailto:ghost_at_c">ghost_at_c</A>...> wrote:<BR>> I think cross-compiling was mentioned on this list a couple of times. Could <BR>> you give more details about your proposed "target-os" feature. Two questions <BR>> that come to mind<BR>> 1. shouldn't 'target-os' feature be optional? <BR>> 2. It it good idea to define various preprocessor symbols, line _WIN32 and <BR>> UNICODE. Shouldn't the compile take care of this?<BR>> </P>
<P>1. I guess you think it should be optional. Because in general,<BR> the development environment is the same as the execution<BR> environment of programs. But I think 'target-os' should be<BR> set in default to the value of 'host-os'. That's why I add <BR> 'HOST_OS' built-in variable in Bjam. In Windows World,<BR> we usually develop the programs for one OS in different OS.<BR> For example, I often write a program for Windows 9x<BR> in Windows 2000.</P>
<P> Of course, cross-compiling is another advanced issue.<BR> I image that the script of BBv2 will explain the<BR> relationship between the values of 'target-os' and 'host-os',<BR> and then transform this into the actions and the arguments which<BR> the compiler or the linker need. If 'target-os' and 'host-os'<BR> are the same, maybe BBv2 just pass through and do nothing.</P>
<P> In addition, it may restrict the choice of toolsets, and<BR> pick up or detect the most popular one for builder<BR> when they doesn't choose one.<BR> <BR> I know the codes I provide is not perfect, but it is just<BR> beginning, not the end. Any opinions or ideas will be fine.<BR> Maybe we can make it better and better together.</P>
<P>2. Mmmm.... The conditional compilations are involved with<BR> Microsoft Platform SDK, not just for an individual toolset,<BR> MSVC, BCB/BCC, or mingw...etc.<BR> No matter what toolset we use, if the programs want to use<BR> the services which the Windows provide, they must include<BR> the header files Microsoft provides. It imply that you must<BR> follow the conditional compilation rules they made.<BR> <BR> Many APIs of the NT-series platform are implemented as<BR> Unicode and ANSI versions in order to compatible with<BR> the Win9x-series. The 'UNICODE' symbol just tells<BR> compiler to use the Unicode version. It seems that<BR> the Win9x-series will be obsolete, and Microsoft provides<BR> MSLU (Microsoft Layer for Unicode on Windows 95/98/Me Systems).<BR> So there is no reason why not use the Unicode version of
APIs<BR> from now on.</P>
<P> But apply 'UNICODE' to all Win32 platform is certainly wrong.<BR> Therefor I fix it already.<BR>> <BR>> Yea, the builtin.jam is really big and should be split. But for splitting it, <BR>> it's ok to use "import". You extra file will work just fine when imported, I <BR>> believe.<BR>> </P>
<P>"import" will work. but what I want to show is to divide<BR>a 'module' into serveral files. As before, a 'module' must<BR>in a single file, it will become larger and larger<BR>in the process of development. If we can split it,<BR>maybe it can be split into the stable codes and the draft ones first.</P>
<P>> I don't understand what you propose. Separate directory for libraries? Or <BR>> different syntax of library initialization?<BR>> </P>
<P>Yes, that's what I mean. Separate directory and<BR>perhaps different syntax of library initialization.</P>
<P>> > Is something wrong within the process of the expansion<BR>> > ?<BR>> <BR>> I don't know. Could you send a testcase for me to look at?<BR>> </P>
<P>I made a sample. You can use your library and unmark the line<BR>which invokes 'feature.compose' rule. The result is so strange...</P>
<P>> The same problem arisen with intel toolset, which, on linux, is <BR>> link-compatible with gcc, so yes, a solution is needed. If you could propose <BR>> one, that would be great. Basically, we need some way to say, <BR>> "<toolset>intel" is compatible with "<toolset>gcc", even if <toolset> is <BR>> link-incompatible. The devil is in the detail -- how to say that.<BR>> </P>
<P>okay, I will express my idea in detail in this weekend.</P>
<P>- Paul Lin</P>
<DIV></DIV></DIV><p><br><hr size=1>
¨C¤Ñ³£ Yahoo!©_¼¯ <br>
®üªºÃC¦â¡B·ªº®ð®§¡B·R§Aªº·Å«×¡AºÉ¦b«H¯È©³¹Ï<br>
<a href="http://tw.promo.yahoo.com/mail_premium/stationery.html">«H¯È©³¹Ï</a> --0-204284882-1066723538=:67909-- --0-1741488750-1066723538=:67909 Content-Type: application/x-zip-compressed; name="testcase.zip"
Content-Transfer-Encoding: base64
Content-Description: testcase.zip
Content-Disposition: attachment; filename="testcase.zip"
[Attachment content not displayed.] --0-1741488750-1066723538=:67909 Content-Type: application/x-zip-compressed; name="builtin.platform.zip"
Content-Transfer-Encoding: base64
Content-Description: builtin.platform.zip
Content-Disposition: attachment; filename="builtin.platform.zip"
[Attachment content not displayed.] --0-1741488750-1066723538=:67909--
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk