Re: Future development

On 10/16/07 22:06, Larry Evans wrote:
> On 10/16/07 16:44, David Abrahams wrote:
>> on Tue Oct 16 2007, Larry Evans
<cppljevans-AT-cox-internet.com> wrote:
> [snip]
>>> But this would require the user to understand
the flags for all the
>>> compilers that are targeted.  Bjam saves the
users this chore by
>>> providing a uniform name for all these flags. 
>> Doug's layer does that for any flags that aren't
portable in practice
>> (i.e. I don't think he did anything for -D and
-I).
>>
> You're right.  I see it in the options call below:
> 
> http://svn.b
oost.org/trac/boost/browser/sandbox-branches/boost-cmake/boo
st_1_34_0/CMakeLists.txt#L51
> 
> Thanks.
Hmm..., but how does cmake know what options are valid for a
*new* 
compiler, such as Doug's variadic template compiler. 
Although
usage of the CMake-env.sh attached here:

http://article.gmane.org/gmane.comp.lib.boost.build/166
32

results in the correct value for CMAKE_CXX_COMPILER:FILEPATH
in the
CMakeCache.txt file, I can't imagine how Doug's layer could
infer
what the valid values for options to this compiler since it
is
new.  I've tried finding the definition of the option macro
on CMakeLists.txt#151 without success. I looked in the
directories:

*/boost-cmake/boost_1_34_0/tools/build/CMake
/usr/share/cmake-2.4/Modules

with the command:

  find . -name *.cmake -exec grep -e 'option' {} ; -ls

without success.

Could some cmake expert point me in the right direction or
tell me how cmake+Doug's layer figures out how to translate
the
uniform names (e.g. the BUILD_SINGLE_THREADED on:

http://svn.b
oost.org/trac/boost/browser/sandbox-branches/boost-cmake/boo
st_1_34_0/CMakeLists.txt#L59

) to the compiler specific options?


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

on Wed Oct 17 2007, Larry Evans
<cppljevans-AT-cox-internet.com> wrote:

> On 10/16/07 22:06, Larry Evans wrote:
>> On 10/16/07 16:44, David Abrahams wrote:
>>> on Tue Oct 16 2007, Larry Evans
<cppljevans-AT-cox-internet.com> wrote:
>> [snip]
>>>> But this would require the user to
understand the flags for all the
>>>> compilers that are targeted.  Bjam saves
the users this chore by
>>>> providing a uniform name for all these
flags. 
>>> Doug's layer does that for any flags that
aren't portable in practice
>>> (i.e. I don't think he did anything for -D and
-I).
>>>
>> You're right.  I see it in the options call below:
>> 
>> http://svn.b
oost.org/trac/boost/browser/sandbox-branches/boost-cmake/boo
st_1_34_0/CMakeLists.txt#L51
>> 
>> Thanks.
>
> Hmm..., but how does cmake know what options are valid
for a *new*
> compiler, such as Doug's variadic template compiler.  

You need to code it up, just as you have to write toolset
code for
BBv2.  In Doug's stuff, IIRC, there's an imperative
if/then/else
statement that checks the compiler and does the flag
translation.  The
really ugly part about this is that all the specific info
about every
compiler we'll support is glommed together into one file, so
you can't
just drop in a new file to add support for a new tool.  I'm
sure that
can be overcome, but I it shows that Doug's code will need
substantial
structural work before it is ongoingly maintainable as
Boost's build
system.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-cons
ulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

Larry Evans wrote:


>> http://svn.b
oost.org/trac/boost/browser/sandbox-branches/boost-cmake/boo
st_1_34_0/CMakeLists.txt#L51
>> 
>> Thanks.
> Hmm..., but how does cmake know what options are valid
for a *new*
> compiler, such as Doug's variadic template compiler. 
Although
> usage of the CMake-env.sh attached here:
> 
> http://article.gmane.org/gmane.comp.lib.boost.build/166
32
> 
> results in the correct value for
CMAKE_CXX_COMPILER:FILEPATH in the
> CMakeCache.txt file, I can't imagine how Doug's layer
could infer
> what the valid values for options to this compiler
since it is
> new.  I've tried finding the definition of the option
macro
> on CMakeLists.txt#151 without success. I looked in the
> directories:
> 
> */boost-cmake/boost_1_34_0/tools/build/CMake
> /usr/share/cmake-2.4/Modules
> 
> with the command:
> 
>   find . -name *.cmake -exec grep -e 'option' {} ;
-ls
> 
> without success.
> 
> Could some cmake expert point me in the right direction
or
> tell me how cmake+Doug's layer figures out how to
translate the
> uniform names (e.g. the BUILD_SINGLE_THREADED on:
> 
> http://svn.b
oost.org/trac/boost/browser/sandbox-branches/boost-cmake/boo
st_1_34_0/CMakeLists.txt#L59
> 
> ) to the compiler specific options?

I start to wonder if this thread has anything to do with
Boost.Build any longer?
It seems purely a discussion of how to do something with
CMake,
and therefore not a topic of this list.

Am I wrong?

- Volodya


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build