Re: [CMake] Building linux kernel module with Cmake

[suhasj]

Oops I missed the main statements...
Sorry for that

Contibuing to the previous post ...

ADD_CUSTOM_COMMAND(OUTPUT DRIVER_BIN_FILE
   COMMAND ${KBUILD_CMD}
   DEPENDS ${MODULE_SOURCE_FILES} VERBATIM
   )

ADD_CUSTOM_TARGET(driver
   DEPENDS ALL DRIVER_BIN_FILE )


> Well there's no ADD_CUSTOM_COMMAND or ADD_CUSTOM_TARGET for one thing.
> :-)
>
> Cheers,
> Brandon Van Every
>
> On Nov 2, 2007 7:40 AM, Suhas Jain <[EMAIL PROTECTED]> wrote:
>> As you said I am using these ADD_CUSTOM_COMMAND / ADD_CUSTOM_TARGET
>> But its not working at my end... please help me out
>> This is what I have in my CMakeLists.txt file
>> ===
>> Set( MODULE_OUTPUT_FILEShello.o
>> hello.mod.c
>> hello.mod.o
>> hello.ko
>> .hello.o.cmd
>> .hello.ko.cmd
>> .hello.mod.o.cmd
>> main.o
>> .main.o.cmd
>> output.o
>> output.o.cmd
>> .tmp_versions/hello.mod
>> .tmp_versions/ )
>>
>> Set( MODULE_SOURCE_FILESoutput.c
>> main.c )
>>
>> Set( DRIVER_FILEhello.ko )
>> Set( DRIVER_TARGET_NAME hello-module )
>> Set( DRIVER_BIN_FILE${CMAKE_BINARY_DIR}/bin/${DRIVER_FILE} )
>> Set( MODULE_SOURCE_DIR  ${CMAKE_CURRENT_BINARY_DIR} )
>>
>> Set( KERNEL_DIR "/lib/modules/2.6.20-16-generic/build" )
>> Set( KBUILD_CMD ${CMAKE_MAKE_PROGRAM}
>> -C ${KERNEL_DIR}
>> M=${MODULE_SOURCE_DIR}
>> modules )
>> =
>>
>> Please point me out if I am doing something wrong. I think I am missing
>> something to add.
>>
>>
>>
>>
>> -Original Message-
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On Behalf Of Brandon
>> Van
>> Every
>> Sent: Friday, November 02, 2007 12:08 AM
>> To: cmake@cmake.org
>> Subject: Re: [CMake] Building linux kernel module with Cmake
>>
>>
>> On Nov 1, 2007 5:48 AM, Suhas Jain <[EMAIL PROTECTED]> wrote:
>> > Thanks for you reply Hendrik
>> > Even I know that Kbuild is a very simple procedure to do so.
>> > But I have a source tree which has applications, drivers and other
>> modules
>> > for different OS as well as hardware architectures and I want to
>> compile
>> all
>> > these folders from a single top level directory. All this can be
>> achieved
>> > with Cmake utlity. I have already compiled other modules.
>> > I want to know if it possible to use cmake for compiling kernel module
>>
>> It would be simpler to use ADD_CUSTOM_COMMAND / ADD_CUSTOM_TARGET to
>> invoke the Linux kernel's native Kbuild, then utilize the results.
>>
>>
>> Cheers,
>> Brandon Van Every
>>
>> ___
>> CMake mailing list
>> CMake@cmake.org
>> http://www.cmake.org/mailman/listinfo/cmake
>>
>>
>>
>>
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Symbian support

[Bill Hoffman]

Brandon Van Every wrote:

On Nov 2, 2007 5:25 AM, Salvatore Iovene
<[EMAIL PROTECTED]> wrote:

Hello,
are there any plans for supporting the symbian platform? I.e. having
CMake generate the build files for Symbian.


Can't imagine why it would be "on the drawing board," so to speak.  Of
course, contributions would probably be welcomed.


If not, could you give me some estimates about how hard a job it'd be?


You're probably in a better position to make the guess, knowing more
about Symbian.



The best place to start would be here:

http://www.cmake.org/Wiki/CMake_Cross_Compiling

I bet it would work without too much trouble.  I am sure Alex would help 
if you had any specific questions after applying what you read in the wiki.


-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Symbian support

[Brandon Van Every]

On Nov 2, 2007 5:25 AM, Salvatore Iovene
<[EMAIL PROTECTED]> wrote:
> Hello,
> are there any plans for supporting the symbian platform? I.e. having
> CMake generate the build files for Symbian.

Can't imagine why it would be "on the drawing board," so to speak.  Of
course, contributions would probably be welcomed.

> If not, could you give me some estimates about how hard a job it'd be?

You're probably in a better position to make the guess, knowing more
about Symbian.


Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[Brandon Van Every]

On Nov 2, 2007 6:51 PM, Justin C. Keesling <[EMAIL PROTECTED]> wrote:
>
> The bottom line is not what is possible, but rather how can we make this build
> system easier to use, more flexible, and more powerful without users having
> to resort to hacks.  Verbose variable prefixes is a hack (one that I
> unfortunately use quite often).

and variable_scope(blah1 blah2 blah3) { } sure smells like a hack.
That was my point.  But if you want to point me towards a popular
language community that does such a thing, feel free.  Or an unpopular
language community, if they have any aesthetic merits to argue.  I'm
leery of trying to "educate" new users about why they should have to
type such things though.  I'd almost prefer to tell them to type long
variable name prefixes, because it's probably easier for them to
accept.


Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[KSpam]

Brandon,

> > Of course, if we could get braces into the mix, it would reduce to:
> >
> >         variable_scope(scratch_preamble got_match not_trail empty)
> >         {
> >                 # [...]
> >                 # my actual code, blah blah blah
> >                 # [...]
> >         }
>
> Why is this better than implementing functions?

I never claimed that it would be better than implementing functions.  For that 
matter, I do not think they would be mutually exclusive.  If changes are 
going to be made, it would benefit us all to consider many alternatives.  
There are pros/cons to each approach.

The nice thing about variable_scope is that it gives you more flexibility for 
the variable within a file, macro, or function.  It allows you to layer 
scopes on top of each other.  You get a nice "stack" of values for a 
particular variable name depending on scope.  This can be a very powerful 
construct, and it allows for recursion.  Furthermore, variable_scope and 
functions are orthogonal features.  I would personally like the synergy that 
comes from having both constructs at my disposal.

On the other hand "SETLOCAL" might be a bit easier for a novice to use.

> > I will trade typing a few more characters for variable safety any day.
>
> You can do that now with verbose variable prefixes.

Ah ... you can do ANYTHING if you are willing to sweat hard enough.  You could 
generate your CMake environment from Python (done that) ... you could write 
macros upon macros (done that) ... you could even create custom CMake plugins 
(done that) ...

The bottom line is not what is possible, but rather how can we make this build 
system easier to use, more flexible, and more powerful without users having 
to resort to hacks.  Verbose variable prefixes is a hack (one that I 
unfortunately use quite often).

Justin
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[Brandon Van Every]

On Nov 2, 2007 5:57 PM, KSpam <[EMAIL PROTECTED]> wrote:
>
> variable_scope_begin(scratch_preamble got_match not_trail empty)
> # [...]
> # my actual code, blah blah blah
> # [...]
> variable_scope_end(scratch_preamble got_match not_trail empty)

That's better, but what happens when I change my variable names and
forget to update this stuff?

> Of course, if we could get braces into the mix, it would reduce to:
>
> variable_scope(scratch_preamble got_match not_trail empty)
> {
> # [...]
> # my actual code, blah blah blah
> # [...]
> }

Why is this better than implementing functions?

> I will trade typing a few more characters for variable safety any day.

You can do that now with verbose variable prefixes.


Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Re: regex ^ does not anchor against the original string

[Brandon Van Every]

On Nov 1, 2007 7:48 PM, Brandon Van Every <[EMAIL PROTECTED]> wrote:
> ^ doesn't anchor against the original input string.  It anchors
> against the string as it is processed!  If replacements cause the
> string to have a new beginning, it anchors against the new beginning.
> I want to say that's a bug.  Do other regex gurus agree, or have I
> just not gone up the learning curve sufficiently?

Perl does not exhibit this behavior, so I've filed a bug.
http://www.cmake.org/Bug/view.php?id=5999
Nobody said CMake is Perl, but Perl regexes are a good baseline for
"sanity" of regex behavior.  I think a ^ anchor should be respected,
and to re-evaluate it "while the string is processed" renders it
meaningless.


Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[KSpam]

Brandon,

You missed the part where Bill mentioned that variable_scope would take 
multiple arguments.  Your example:

> variable_scope_begin(scratch_preamble)
> variable_scope_begin(got_match)
> variable_scope_begin(not_trail)
> variable_scope_begin(empty)
> # [...]
> # my actual code, blah blah blah
> # [...]
> variable_scope_end(scratch_preamble)
> variable_scope_end(got_match)
> variable_scope_end(not_trail)
> variable_scope_end(empty)

would reduce to:

variable_scope_begin(scratch_preamble got_match not_trail empty)
# [...]
# my actual code, blah blah blah
# [...]
variable_scope_end(scratch_preamble got_match not_trail empty)

Of course, if we could get braces into the mix, it would reduce to:

variable_scope(scratch_preamble got_match not_trail empty)
{
# [...]
# my actual code, blah blah blah
# [...]
}

I think that looks pretty good.  Even without the braces, the construct is 
optional, and it provides a significant improvement in variable safety.  I 
will trade typing a few more characters for variable safety any day.

Justin
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[Brandon Van Every]

On Nov 2, 2007 5:08 PM, Brandon Van Every <[EMAIL PROTECTED]> wrote:
> On Nov 2, 2007 5:02 PM, KSpam <[EMAIL PROTECTED]> wrote:
> > Bill,
> >
> > > set(a "world")
> > > variable_scope_begin(a)
> > > set(a "hello")
> > > message(${a})
> > > variable_scope_end(a)
> > > message(${a})
> >
> > This would be a workable solution for me.  It would certainly be a step in 
> > the
> > right direction, especially if it is easy enough to implement.  [...]
> > The whole "begin ... end" construct gets to be tedious after a while.
>
> Once it's introduced, we're gonna get stuck with it.  Please don't
> just do what's expedient.  Do something that will increase the
> likeability of CMake.

Oh, and I don't want macros that provide scope for only 1 variable at
a time.  When I write a macro that's really supposed to be a function,
I've got lotsa variables that I don't want the outside world to see.
This ain't gonna happen in the real world:

variable_scope_begin(scratch_preamble)
variable_scope_begin(got_match)
variable_scope_begin(not_trail)
variable_scope_begin(empty)
# [...]
# my actual code, blah blah blah
# [...]
variable_scope_end(scratch_preamble)
variable_scope_end(got_match)
variable_scope_end(not_trail)
variable_scope_end(empty)

This is also leaving out the issue of whether macro argument names can
shadow each other.  I haven't really investigated that yet.  If they
can, then that's even more scopes to cook up.

The cure is no better than the disease.  I'm already using
splitonlastword_ disambiguators.  In a short function, I'd still be
typing a similar number of extra characters and it would still be a
PITA.


Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[Brandon Van Every]

On Nov 2, 2007 5:02 PM, KSpam <[EMAIL PROTECTED]> wrote:
> Bill,
>
> > set(a "world")
> > variable_scope_begin(a)
> > set(a "hello")
> > message(${a})
> > variable_scope_end(a)
> > message(${a})
>
> This would be a workable solution for me.  It would certainly be a step in the
> right direction, especially if it is easy enough to implement.  [...]
> The whole "begin ... end" construct gets to be tedious after a while.

Once it's introduced, we're gonna get stuck with it.  Please don't
just do what's expedient.  Do something that will increase the
likeability of CMake.


Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[KSpam]

Bill,

> set(a "world")
> variable_scope_begin(a)
> set(a "hello")
> message(${a})
> variable_scope_end(a)
> message(${a})

This would be a workable solution for me.  It would certainly be a step in the 
right direction, especially if it is easy enough to implement.  I was into 
PERL years ago, so "my" declarations are still ingrained in my head ... try 
writing a large set of PERL scripts without "use strict" and "my" :-)

It sure would be nice if there were more standard ways to denote scope though.  
The whole "begin ... end" construct gets to be tedious after a while.  I am a 
big fan of curly braces ( { ... } ) personally, although I am sure that this 
would require quite a bit more work to the CMake scripting language.

With a construct to control variable scope and curly braces to 
replace "begin ... end", I would be quite satisfied with CMake scripting :-)

Thanks,
Justin
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[Brandon Van Every]

On Nov 2, 2007 4:34 PM, Juan Sanchez <[EMAIL PROTECTED]> wrote:
>
> I guess the best way to fix your issue would be to move to a lua frontend.

It's a way.  Another way is to add functions to CMake script.

I've started looking at Lua games on Sourceforge, as an excuse to
learn something about it.  Possibly at some point in the future I'll
be in a position to comment on whether Lua is "worth it."  The
potential to sell game console developers on $$ build systems is
not lost on me.


Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[Juan Sanchez]

Oh,

I guess you did.  My apologies.

I guess the best way to fix your issue would be to move to a lua frontend.

Juan

Brandon Van Every wrote:
> On Nov 2, 2007 4:22 PM, Juan Sanchez <[EMAIL PROTECTED]> wrote:
>> My suggestion as a temporary work around would be to apply a namespace
>> prefix to the variables in your macro.
> 
> That's what my example is.  I even pointed out the naming policy I
> use.  I want to talk about making things better, not how to work
> around the issue at present.  I already know how to do that, and the
> point is, it's a PITA.  The more PITA in CMake, the slower the
> adoption rate.
> 
> 
> Cheers,
> Brandon Van Every


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[Brandon Van Every]

On Nov 2, 2007 4:22 PM, Juan Sanchez <[EMAIL PROTECTED]> wrote:
> My suggestion as a temporary work around would be to apply a namespace
> prefix to the variables in your macro.

That's what my example is.  I even pointed out the naming policy I
use.  I want to talk about making things better, not how to work
around the issue at present.  I already know how to do that, and the
point is, it's a PITA.  The more PITA in CMake, the slower the
adoption rate.


Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[Juan Sanchez]

My suggestion as a temporary work around would be to apply a namespace
prefix to the variables in your macro.

Create the macro with short variable names x.
Test
Replace variable names with uniques ones MACRO_DOIT_x
Release

If included in another file, your users don't have to see the munged
code underneath.

Juan

Brandon Van Every wrote:
> On Nov 2, 2007 4:13 PM, Bill Hoffman <[EMAIL PROTECTED]> wrote:
>> Brandon Van Every wrote:
>>> On Nov 2, 2007 3:44 PM, Bill Hoffman <[EMAIL PROTECTED]> wrote:
 I have an idea.  What if we created a variable_scope command?
>>> Bad markerting idea.  Nobody programs in this idiom.  (Well, I don't
>>> know about Perl, as far as I'm concerned they're nobody.  ;-)  Lotsa
>>> people program with functions and would expect a scripting language to
>>> have functions.  Minimize the number of "CMake specific weird things"
>>> people have to learn, if you want more users.  SETLOCAL is not so
>>> objectionable, didn't some Unix shells have this historically?
>>>
>> The problem is what does SETLOCAL mean?   There is no scope in cmake
>> right now.  So, I guess you are saying add functions.
> 
> Yep.
> 
>> I am not even
>> sure what those will be...  Many languages have the idea of scope.
>> Braces in C++.   This would just be a way of creating scope.
> 
> Then add braces.  Not some begin_long_thing_word end_long_thing_word.
> Nobody does that, nobody will like it.
> 
> 
> Cheers,
> Brandon Van Every
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
> 
> 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[Brandon Van Every]

On Nov 2, 2007 2:39 PM, Brandon Van Every <[EMAIL PROTECTED]> wrote:
>
> SET and SETLOCAL is one possibility.  I could live with it.

While we're at it, how difficult would it be for functions to return a
value that can be used in other contexts?  GMake has $(whatever ...)
functions that can be used directly in strings.  A lot of my
translation code is lifting those things out of their strings and
putting them on previous lines.  Translations would be easier if
people could just do what they're used to doing, in some analogous
manner.


Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[Brandon Van Every]

On Nov 2, 2007 4:13 PM, Bill Hoffman <[EMAIL PROTECTED]> wrote:
>
> Brandon Van Every wrote:
> > On Nov 2, 2007 3:44 PM, Bill Hoffman <[EMAIL PROTECTED]> wrote:
> >> I have an idea.  What if we created a variable_scope command?
> >
> > Bad markerting idea.  Nobody programs in this idiom.  (Well, I don't
> > know about Perl, as far as I'm concerned they're nobody.  ;-)  Lotsa
> > people program with functions and would expect a scripting language to
> > have functions.  Minimize the number of "CMake specific weird things"
> > people have to learn, if you want more users.  SETLOCAL is not so
> > objectionable, didn't some Unix shells have this historically?
> >
> The problem is what does SETLOCAL mean?   There is no scope in cmake
> right now.  So, I guess you are saying add functions.

Yep.

> I am not even
> sure what those will be...  Many languages have the idea of scope.
> Braces in C++.   This would just be a way of creating scope.

Then add braces.  Not some begin_long_thing_word end_long_thing_word.
Nobody does that, nobody will like it.


Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[Bill Hoffman]

Brandon Van Every wrote:

On Nov 2, 2007 3:44 PM, Bill Hoffman <[EMAIL PROTECTED]> wrote:

I have an idea.  What if we created a variable_scope command?


Bad markerting idea.  Nobody programs in this idiom.  (Well, I don't
know about Perl, as far as I'm concerned they're nobody.  ;-)  Lotsa
people program with functions and would expect a scripting language to
have functions.  Minimize the number of "CMake specific weird things"
people have to learn, if you want more users.  SETLOCAL is not so
objectionable, didn't some Unix shells have this historically?

The problem is what does SETLOCAL mean?   There is no scope in cmake 
right now.  So, I guess you are saying add functions.  I am not even 
sure what those will be...  Many languages have the idea of scope. 
Braces in C++.   This would just be a way of creating scope.



-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[Brandon Van Every]

On Nov 2, 2007 3:44 PM, Bill Hoffman <[EMAIL PROTECTED]> wrote:
> I have an idea.  What if we created a variable_scope command?

Bad markerting idea.  Nobody programs in this idiom.  (Well, I don't
know about Perl, as far as I'm concerned they're nobody.  ;-)  Lotsa
people program with functions and would expect a scripting language to
have functions.  Minimize the number of "CMake specific weird things"
people have to learn, if you want more users.  SETLOCAL is not so
objectionable, didn't some Unix shells have this historically?


Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[Bill Hoffman]

I have an idea.  What if we created a variable_scope command?

Something like this:

set(a "world")
variable_scope_begin(a)
set(a "hello")
message(${a})
variable_scope_end(a)
message(${a})


The above would print out:
hello
world

This could be done with the current macros, or even an include file of 
cmake without having to create the idea of a function.  You could of 
course pass in a list of variables to variable_scope. It would be sort 
of like the "my" in perl.   I don't think it would be that hard to 
implement this, and it would be backwards compatible, and not make the 
set command any more complicated.  You could nest them as well.  It 
could cause some odd things to happen if you forgot to add the 
scope_end, but it might fix more things than it breaks.


-Bill



___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] FIND_PATH

[Leon Moctezuma]

Hi, I created a FindGECKO  modul, which tries
to look for the NPAPI headers for creating
FireFox plug-ins, the problem is that in some
distributions the paths have directories with
it's version number... for example:

/usr/include/firefox-2.0.0.5
/usr/include/nspr4

here is part of the actual script:

FIND_PATH(GECKO_ROOT_DIR npapi.h npupp.h /usr/include/firefox
/usr/local/include/firefox)
FIND_PATH(GECKO_NSPR_DIR prthread.h ${GECKO_ROOT_DIR}/nspr)

Is there a way to look for in all FireFox* or nspr* directories?

Best  regards,

Leon
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[KSpam]

Ken,

> But to the question at hand...adding scope to variables. Variables have
> scope right now of
>
> 1) the CMakeListfile they are defined in
> 2) any included files that are included after the variable is set
> 3) and subdirectories of the directory they were defined in and processed
> after the setting of the variable
> 4) they can be access globally using get_directory_property and specifying
> the directory etc

I do like the effect of "cascading" variables down the CMakeLists.txt 
hierarchical structure.  This is very handy.  Of course, for variables that 
are not required to be passed down the chain, this is a maintenance headache.  
IMHO, your solution of adding functions would resolve much of this headache.

> the macro command is like a cpp macro so scoping does not make a lot of
> sense for it. What would/could make sense is a function command that
> creates a function. (think of the difference in a macro versus a function
> in c, macros have no inherent scope they are just string replacements,
> functions do have scope built in). With a function command we could
> probably figure out some way to create variables that are scoped to the
> function only. Most of the places we are using macros really could/should
> be functions. My main question would be if we had a function, how would you
> want variables handled.

I agree that most macros would be better suited as functions.  I am certain 
that this is the case for my projects.  I would suspect that 80% of my macros 
should really be functions.

> 1) all set commands create "local" variables to the function (a mess for
> functions that do an include of other cmake code)
> 2) a special set command or signature that creates a local variable scoped
> to the current function
> 3) a mode to switch the behavior of set (yuck)
> 4) something else

My vote would be for 2.  I like to be able to grep my CMakeLists.txt files.  
Having two set commands (or signatures) would ease the task of grepping 
for "global" vs. local variables.  This would also make it easy to set either 
type of variable in a function definition.

Thanks,
Justin
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[Brandon Van Every]

On Nov 2, 2007 2:26 PM, Ken Martin <[EMAIL PROTECTED]> wrote:
>
> the macro command is like a cpp macro so scoping does not make a lot of
> sense for it. What would/could make sense is a function command that creates
> a function. (think of the difference in a macro versus a function in c,
> macros have no inherent scope they are just string replacements, functions
> do have scope built in). With a function command we could probably figure
> out some way to create variables that are scoped to the function only. Most
> of the places we are using macros really could/should be functions.

Yes please!  95% of MACROs I've written are really trying to be functions.

> My main
> question would be if we had a function, how would you want variables
> handled.
>
> 1) all set commands create "local" variables to the function (a mess for
> functions that do an include of other cmake code)
> 2) a special set command or signature that creates a local variable scoped
> to the current function

SET and SETLOCAL is one possibility.  I could live with it.
SET and SETGLOBAL is another possibility.  It would require breaking
backwards compatibility.

> 3) a mode to switch the behavior of set (yuck)

No.  For stability of developing a build system, that's completely ridiculous.


Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Lua

[Brandon Van Every]

On Nov 2, 2007 1:57 PM, Brandon Van Every <[EMAIL PROTECTED]> wrote:
> On Nov 2, 2007 1:01 PM, Juan Sanchez <[EMAIL PROTECTED]> wrote:
> >
> > I'd be willing to entertain any other suggestions for scripting
> > languages, as long as:
> > 1. the syntax is consistent
> > 2. the language is not bloated
> > 3. the language does not require to much dressing up with parenthesis
> > and commas
> > 4. the license is BSD-like in nature.
>
> Lua is MIT licensed.  http://www.lua.org/license.html  Lua is
> extremely embedded-friendly, that's its sole reason for existing.  Lua
> has brand identity in the world of modern geekdom but is not,
> generally speaking, anywhere near as popular as Python or Ruby.  It is
> quite popular in the game industry, however, because of a perception
> that it's "lean and mean."  I have no idea how beneficial or
> detrimental the language syntax is, I've never used it.  Lua's pattern
> matching has character classes but not the "|" branching operator.
> http://www.lua.org/manual/5.1/manual.html#5.4.1

Looks like POSIX regexes and PCRE are readily obtained though.
http://luaforge.net/projects/lrexlib/

Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

RE: [CMake] lexical scoping

[Ken Martin]

Variables can be a PITA :) They have unusual scoping, mixed documentation,
etc. In CVS there have been some changes. We have extended the concept of
properties which are scoped to an object (source file, target, directory,
global, test, for example) and are documented, can be inherited, and can be
tested to verify they are documented. This is nice and meets some needs of
CMake. But ... there are still variables.  Recently Bill and I have started
documenting variables in the source code (cmake --help-variables works) such
that you can get documentation on supported variables in cmake. These
documented variables are the ones we will try to keep backwards compatible
(tm), all others are up in the air.

But to the question at hand...adding scope to variables. Variables have
scope right now of

1) the CMakeListfile they are defined in
2) any included files that are included after the variable is set
3) and subdirectories of the directory they were defined in and processed
after the setting of the variable
4) they can be access globally using get_directory_property and specifying
the directory etc

the macro command is like a cpp macro so scoping does not make a lot of
sense for it. What would/could make sense is a function command that creates
a function. (think of the difference in a macro versus a function in c,
macros have no inherent scope they are just string replacements, functions
do have scope built in). With a function command we could probably figure
out some way to create variables that are scoped to the function only. Most
of the places we are using macros really could/should be functions. My main
question would be if we had a function, how would you want variables
handled.

1) all set commands create "local" variables to the function (a mess for
functions that do an include of other cmake code)
2) a special set command or signature that creates a local variable scoped
to the current function
3) a mode to switch the behavior of set (yuck)
4) something else

Ken

Ken Martin PhD 
Kitware Inc.
28 Corporate Drive
Clifton Park NY 12065
518 371 3971 
 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On 
> Behalf Of KSpam
> Sent: Friday, November 02, 2007 1:32 PM
> To: cmake@cmake.org
> Subject: Re: [CMake] lexical scoping
> 
> On Friday 02 November 2007 09:54:51 Brandon Van Every wrote:
> > Is it feasible to modify the CMake language to have lexical scoping?
> 
> I agree.  The lack of variable scoping is currently my 
> biggest annoyance with 
> custom macros.  Additionally, I believe that custom macros 
> are pretty much 
> required for any mid to large scale project.  Life in the 
> CMake scripting 
> language would be so much nicer if we could scope variables 
> at the macro 
> and/or file level.
> 
> Justin
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] improve the CMake language?

[Olivier Delannoy]

-- Forwarded message --
From: Olivier Delannoy <[EMAIL PROTECTED]>
Date: Nov 2, 2007 7:24 PM
Subject: Re: [CMake] improve the CMake language?
To: Ken Martin <[EMAIL PROTECTED]>


Lua has developed something which can be used to change the syntax of
the language (syntax not semantic). This might for example allow a
cmake script to be translated during the parsing stage, made by lua
parser, of the document into a lua program equivalent. I haven't used
it might self so I don't know how much work it means but if a
scripting language is to be used to replace CMake language, Lua and
its tokens filtering can be used to ensure backward compatibility
quite easly without needing the maintenance of two language at the
same time.

On 11/2/07, Ken Martin <[EMAIL PROTECTED]> wrote:
> I have looked at incorporating Lua into CMake as an alternate language. Lua
> because it is designed to be embedded into projects as a language, not a
> toolkit and it is tiny and well documented, so adding it to the CMake tree
> would be a no brainer. Things like Python, Tcl, Java etc are much larger and
> tend to drag in a lot of extra things a language does not need. (I think I
> have a CMake tree lying around that includes Lua and links it in) Having
> said that, even though CMake has a pretty clean divide between
> commands/language and the rest of the work, it is still a fairly big task.
> The easiest solution being to support both languages (CMake plus Lua) so
> that all the Modules and Platform files can continue to be used. Having said
> all this it is a low priority for me as I am still not sure of the
> practicality and net benefits of it. etc.
>
> Ken
>
> Ken Martin PhD
> Kitware Inc.
> 28 Corporate Drive
> Clifton Park NY 12065
> 518 371 3971
>
>
>
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>


-- 
Olivier Delannoy
Ph.D. Student
PRiSM Laboratory
Versailles University, FRANCE
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

RE: [CMake] improve the CMake language?

[Ken Martin]

I have looked at incorporating Lua into CMake as an alternate language. Lua
because it is designed to be embedded into projects as a language, not a
toolkit and it is tiny and well documented, so adding it to the CMake tree
would be a no brainer. Things like Python, Tcl, Java etc are much larger and
tend to drag in a lot of extra things a language does not need. (I think I
have a CMake tree lying around that includes Lua and links it in) Having
said that, even though CMake has a pretty clean divide between
commands/language and the rest of the work, it is still a fairly big task.
The easiest solution being to support both languages (CMake plus Lua) so
that all the Modules and Platform files can continue to be used. Having said
all this it is a low priority for me as I am still not sure of the
practicality and net benefits of it. etc.

Ken

Ken Martin PhD 
Kitware Inc.
28 Corporate Drive
Clifton Park NY 12065
518 371 3971 
 


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] improve the CMake language?

[Brandon Van Every]

On Nov 2, 2007 1:01 PM, Juan Sanchez <[EMAIL PROTECTED]> wrote:
>
> Brandon Van Every wrote:
> > On Nov 2, 2007 11:49 AM, Juan E. Sanchez <[EMAIL PROTECTED]> wrote:
> >> On Fri, 2 Nov 2007, Brandon Van Every wrote:
> >>> To make real improvements in all of those areas, you'd need a lot of
> >>> funding.  What kind of mandate do you have?  There's not much point in
> >>> saying "everything's gonna be better" if you don't have the labor.
> >> This would be a community effort.  I don't have the resources to
> >> strike out on my own.
> >
> > Without a bunch of gold bars at your disposal, I'd say the CMake
> > community isn't going anywhere.  Best to work on compromises within
> > the community rather than sweeping changes.
> >
> >> I like using cmake.  The language is kind of a
> >> bitter pill for people in my organization to swallow.
> >>
> >> The most important item on my proposed feature list is the Tcl
> >> frontend.
> >
> > I know everyone champions their favorite scripting language, but my
> > opinion is, if you go that route you're doomed.  Pick something that
> > programmers consider modern and sexy, or you're never going to get the
> > mindshare.  A key consideration that dominates my own thinking as of
> > late: "Who's gonna pay me to know language X ?"  I went back to C++
> > for this reason.  I'm sorry but whatever its merits, Tcl is not a
> > resume skill nowadays.
>
> Actually Tcl is still quite popular.  Many commercial electronic design
> automation (EDA) companies use Tcl frontends, and EDA is a billion
> dollar industry.  Active State still seems to be doing well peddling
> their supported versions of Tcl as well.
>
> Apart from its consistent syntax, another big selling point is its truly
> free license.
>
> I'd be willing to entertain any other suggestions for scripting
> languages, as long as:
> 1. the syntax is consistent
> 2. the language is not bloated
> 3. the language does not require to much dressing up with parenthesis
> and commas
> 4. the license is BSD-like in nature.

I didn't realize that Ruby is GPLed.  http://www.ruby-lang.org/en/LICENSE.txt
Oh well, so much for embedding Ruby!

Python is essentially BSD + requires that you make brief note of any
changes to Python in derivative works.
http://www.python.org/download/releases/2.5.1/license/  I don't know
how embedded-friendly Python is, particularly in the presence of other
Python installations.  Python regexes are not inherently part of the
syntax; of course, this is true of CMake script as well.  Python
certainly wins popularity contests, and a Python CMake done well would
put SCons out of business + maybe steal their developers.

Lua is MIT licensed.  http://www.lua.org/license.html  Lua is
extremely embedded-friendly, that's its sole reason for existing.  Lua
has brand identity in the world of modern geekdom but is not,
generally speaking, anywhere near as popular as Python or Ruby.  It is
quite popular in the game industry, however, because of a perception
that it's "lean and mean."  I have no idea how beneficial or
detrimental the language syntax is, I've never used it.  Lua's pattern
matching has character classes but not the "|" branching operator.
http://www.lua.org/manual/5.1/manual.html#5.4.1

That's pretty much it for the list of suspects.  I wouldn't hitch the
CMake truck to Perl.

> Note that OOP is more of a detriment than a benefit in my concept of
> "simple" scripting languages.  Obfuscation by encapsulation is not a
> benefit in a flat file architecture.

You can write your non-OOP code however you want, and leave others to
do what they want.  It doesn't matter as far as off-the-shelf
languages go.


Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[KSpam]

On Friday 02 November 2007 09:54:51 Brandon Van Every wrote:
> Is it feasible to modify the CMake language to have lexical scoping?

I agree.  The lack of variable scoping is currently my biggest annoyance with 
custom macros.  Additionally, I believe that custom macros are pretty much 
required for any mid to large scale project.  Life in the CMake scripting 
language would be so much nicer if we could scope variables at the macro 
and/or file level.

Justin
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] disabling the cache

[Jesper Eskilson]

Philip Lowman wrote:


And a related note here is Visual Studio's inability to detect that
preprocessor definitions or dependent libraries have changed in a VCproj
file and rebuild or relink the target accordingly.


Don't get me started on the limitations of Visual Studio, please. ;-)

--
/Jesper

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] improve the CMake language?

[Juan Sanchez]

Brandon Van Every wrote:
> On Nov 2, 2007 11:49 AM, Juan E. Sanchez <[EMAIL PROTECTED]> wrote:
>> On Fri, 2 Nov 2007, Brandon Van Every wrote:
>>> To make real improvements in all of those areas, you'd need a lot of
>>> funding.  What kind of mandate do you have?  There's not much point in
>>> saying "everything's gonna be better" if you don't have the labor.
>> This would be a community effort.  I don't have the resources to
>> strike out on my own.
> 
> Without a bunch of gold bars at your disposal, I'd say the CMake
> community isn't going anywhere.  Best to work on compromises within
> the community rather than sweeping changes.
> 
>> I like using cmake.  The language is kind of a
>> bitter pill for people in my organization to swallow.
>>
>> The most important item on my proposed feature list is the Tcl
>> frontend.
> 
> I know everyone champions their favorite scripting language, but my
> opinion is, if you go that route you're doomed.  Pick something that
> programmers consider modern and sexy, or you're never going to get the
> mindshare.  A key consideration that dominates my own thinking as of
> late: "Who's gonna pay me to know language X ?"  I went back to C++
> for this reason.  I'm sorry but whatever its merits, Tcl is not a
> resume skill nowadays.

Actually Tcl is still quite popular.  Many commercial electronic design
automation (EDA) companies use Tcl frontends, and EDA is a billion
dollar industry.  Active State still seems to be doing well peddling
their supported versions of Tcl as well.

Apart from its consistent syntax, another big selling point is its truly
free license.

I'd be willing to entertain any other suggestions for scripting
languages, as long as:
1. the syntax is consistent
2. the language is not bloated
3. the language does not require to much dressing up with parenthesis
and commas
4. the license is BSD-like in nature.

Note that OOP is more of a detriment than a benefit in my concept of
"simple" scripting languages.  Obfuscation by encapsulation is not a
benefit in a flat file architecture.

Regards,

Jun


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] lexical scoping

[Brandon Van Every]

Is it feasible to modify the CMake language to have lexical scoping?

My code would be a lot more readable and bug free if I didn't have to
write things like this all day long:

MACRO(SPLIT_ON_LASTWORD the_stream the_word
  splitonlastword_preamble splitonlastword_got_match splitonlastword_trail
  )
  # splitonlastword_preamble or splitonlastword_trail could evaluate
to the same thing as the_stream, so don't use them directly.
  # Don't modify splitonlastword_preamble or splitonlastword_trail if
there's no match.
  PREAMBLE_LASTWORD(${the_stream} ${the_word}
splitonlastword_scratch_preamble ${splitonlastword_got_match})
  IF(${splitonlastword_got_match})
SET(splitonlastword_not_trail
"${splitonlastword_scratch_preamble}${the_word}")
SET(splitonlastword_empty "")
# read the_stream first!  The replaced arguments could evaluate to
the_stream.
REPLACE_FIRST(
  splitonlastword_not_trail
  splitonlastword_empty
  ${splitonlastword_trail} ${the_stream})
SET(${splitonlastword_preamble} "${splitonlastword_scratch_preamble}")
  ELSE(${splitonlastword_got_match})
SET(${splitonlastword_preamble})
SET(${splitonlastword_trail})
  ENDIF(${splitonlastword_got_match})
ENDMACRO(SPLIT_ON_LASTWORD)

This is just a helper function, that relies in turn on 2 other helper
functions.  Why do I end up writing such things at all?  I think it
happens when you're trying to build a 400MB codebase.  You just end up
needing more stuff than CMake inherently has.  I imagine CMake module
authors are in a similar position.

The only disambiguation convention I've come up with, that I can count
on preventing errors no matter how much code I write, is to use some
form of the entire function name as a prefix.  Previously I was using
an acronym of the function name as a prefix.  But I started noticing
it was pretty likely I'd end up with the same three letter acronyms at
some point.  Prefixes like "the_" or "my_" don't disambiguate
anything, they become common patterns as I continue to code.  The only
reason I've still got the_ prefixes is because those arguments are
supposed to be read-only, so aliasing shouldn't matter.


Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Building linux kernel module with Cmake

[Brandon Van Every]

Well there's no ADD_CUSTOM_COMMAND or ADD_CUSTOM_TARGET for one thing.  :-)

Cheers,
Brandon Van Every

On Nov 2, 2007 7:40 AM, Suhas Jain <[EMAIL PROTECTED]> wrote:
> As you said I am using these ADD_CUSTOM_COMMAND / ADD_CUSTOM_TARGET
> But its not working at my end... please help me out
> This is what I have in my CMakeLists.txt file
> ===
> Set( MODULE_OUTPUT_FILEShello.o
> hello.mod.c
> hello.mod.o
> hello.ko
> .hello.o.cmd
> .hello.ko.cmd
> .hello.mod.o.cmd
> main.o
> .main.o.cmd
> output.o
> output.o.cmd
> .tmp_versions/hello.mod
> .tmp_versions/ )
>
> Set( MODULE_SOURCE_FILESoutput.c
> main.c )
>
> Set( DRIVER_FILEhello.ko )
> Set( DRIVER_TARGET_NAME hello-module )
> Set( DRIVER_BIN_FILE${CMAKE_BINARY_DIR}/bin/${DRIVER_FILE} )
> Set( MODULE_SOURCE_DIR  ${CMAKE_CURRENT_BINARY_DIR} )
>
> Set( KERNEL_DIR "/lib/modules/2.6.20-16-generic/build" )
> Set( KBUILD_CMD ${CMAKE_MAKE_PROGRAM}
> -C ${KERNEL_DIR}
> M=${MODULE_SOURCE_DIR}
> modules )
> =
>
> Please point me out if I am doing something wrong. I think I am missing
> something to add.
>
>
>
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Brandon Van
> Every
> Sent: Friday, November 02, 2007 12:08 AM
> To: cmake@cmake.org
> Subject: Re: [CMake] Building linux kernel module with Cmake
>
>
> On Nov 1, 2007 5:48 AM, Suhas Jain <[EMAIL PROTECTED]> wrote:
> > Thanks for you reply Hendrik
> > Even I know that Kbuild is a very simple procedure to do so.
> > But I have a source tree which has applications, drivers and other modules
> > for different OS as well as hardware architectures and I want to compile
> all
> > these folders from a single top level directory. All this can be achieved
> > with Cmake utlity. I have already compiled other modules.
> > I want to know if it possible to use cmake for compiling kernel module
>
> It would be simpler to use ADD_CUSTOM_COMMAND / ADD_CUSTOM_TARGET to
> invoke the Linux kernel's native Kbuild, then utilize the results.
>
>
> Cheers,
> Brandon Van Every
>
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>
>
>
>
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] improve the CMake language?

[Brandon Van Every]

On Nov 2, 2007 11:49 AM, Juan E. Sanchez <[EMAIL PROTECTED]> wrote:
> On Fri, 2 Nov 2007, Brandon Van Every wrote:
> >
> > To make real improvements in all of those areas, you'd need a lot of
> > funding.  What kind of mandate do you have?  There's not much point in
> > saying "everything's gonna be better" if you don't have the labor.
>
> This would be a community effort.  I don't have the resources to
> strike out on my own.

Without a bunch of gold bars at your disposal, I'd say the CMake
community isn't going anywhere.  Best to work on compromises within
the community rather than sweeping changes.

> I like using cmake.  The language is kind of a
> bitter pill for people in my organization to swallow.
>
> The most important item on my proposed feature list is the Tcl
> frontend.

I know everyone champions their favorite scripting language, but my
opinion is, if you go that route you're doomed.  Pick something that
programmers consider modern and sexy, or you're never going to get the
mindshare.  A key consideration that dominates my own thinking as of
late: "Who's gonna pay me to know language X ?"  I went back to C++
for this reason.  I'm sorry but whatever its merits, Tcl is not a
resume skill nowadays.


Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

re: [CMake] improve the CMake language?

[Brandon Van Every]

On Nov 2, 2007 6:04 AM, Eric Noulard <[EMAIL PROTECTED]> wrote:
>
> >  Many features in the CMake language don't really work the way people
> > expect, or are not documented, or both.
>
> Documentation is not as good as it should be
> but re-implementing something (either TCL, Python, Perl)
> won't make the documentation better.

Actually for language syntax issues, which CMake certainly has, the
documentation would become tremendously better.  And Kitware wouldn't
have to maintain that documentation at all.  There would be a
bazillion Python or Ruby examples to choose from out on the net.  In
another thread I've asked about adding PCRE.  One of the main benefits
I see in PCRE is it's well-documented, whereas the CMake regex engine
is not.

I agree that "how to use this CMake function to do XYZ" won't improve
by re-implementing CMake in another language.  It's an orthogonal
problem.


Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] improve the CMake language?

[Brandon Van Every]

On Nov 2, 2007 9:04 AM, Gonzalo Garramuño <[EMAIL PROTECTED]> wrote:
> Brandon Van Every wrote:
> >
> > My concern is that if the status quo is maintained, CMake script will
> > always be ugly to program with.
>
> Yes.  No doubt about that.  It is already uglier to program with than
> most modern scripting languages.
> Personally I think you need to see cmake as what it is: a tool to create
> makefiles.  Not a scripting language.

But I think this is the wrong idea from a marketing standpoint.
Programmers are programmers.  They don't care what they're
programming.  If you tell 'em to "suck it up," they don't wanna hear
it.  They'll just go use something that's more pleasant to work with,
if it exists somewhere.  And if it doesn't, they'll write it!  I don't
see any inherent reason why Makefile programming has to be tons uglier
than "regular" programming.  It's just the historical accident of
where the implementation is at.  Sooner or later, someone's going to
decide that Makefile programming doesn't have to suck.  Then that
Makefile language is going to become popular.  It could be CMake, with
a little planning.

> If you are doing lots of file,
> regex or string manipulation... alarms should be going off.  You should
> probably write that as a small tool in ruby, perl or python and have
> cmake just call the command.

Yes I probably should have written my (Autoconf + GMake) --> CMake
translator in Ruby.  But I didn't know Ruby and I did know CMake
script.  I wanted to see how far I could get with CMake regexes and
macro constructions, and I found out.  You know, frankly, I could get
a lot farther with some pretty basic language improvements.  Like a
better regex engine, macro string passing that doesn't mess up the
escapes, and lexical scoping.  I don't need "fancy dynamic" scripting
stuff to scale up CMake quite a bit more.  Currently my code is 3
macros deep.

>  > I'm not just talking about SCons and so forth.
>
> python scons, ruby's rake and jam are (currently) cmake's closest
> contenders.

Don't forget Ant.  As far as I'm concerned, a "CMake contender" is any
build system that is very popular and can supplant the jobs that CMake
does.

> > we'll write our own
> > custom build system in our favorite scripting language.  It happens in
> > the game industry all the time.
> >
>
> Does it?  I work in a related industry and I never heard of such.  Only
> very large companies can afford that kind of luxury.

Game developers are an extremely immature lot.  They will write new
build systems and new scripting languages because they can.  Meaning,
because they've fooled someone into paying them to do it.  The game
developer postmortems are filled with stories of "we made this
scripting language, it did things X Y Z for us, but it took forever
and we really suffered from tools immaturity."  Yet the industry keeps
doing it over and over again.  You could say that basically it's an
industry of technical ferment.  I hang out on the sweng-gamedev
mailing list, and I'm forever hearing about guys who think a
cross-platform build system is hacking Visual Studio .sln files to
export values to other platforms.  They'll drive everything from
Visual Studio or some such.  Scripting language gurus are a real
threat to software stability.  They're getting paid, and like a
standing army they're gonna find a way to get used.

> That being said, the gaming industry is also mostly oriented towards one
> or two platforms, so the need for a comprehensive multiplatform system
> like cmake is also probably overkill.

The mainstream game industry is oriented towards Windows, Sony
Playstation3, Nintendo Wii, and XBox360.  They need comprehensive
cross-platform build systems and it appears that none exist yet.  So
it is with an eye towards stalking them that I ask these questions.
I'd like to get paid to do things related to game industry concerns,
seeing as how I'm an indie game developer.  Rather than the orthogonal
"open source pays my bills" stuff I'm currently doing.

Mainstream game titles often have multi-million $ budgets and teams of
100 people working on them.  Granted, the bulk of those are artists.
Asset management systems are a big deal in the game industry.


Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] improve the CMake language?

[Brandon Van Every]

On Nov 1, 2007 11:40 PM, Sanchez, Juan <[EMAIL PROTECTED]> wrote:
>
>  Tcl is a simple language, and is well understood.  It has already been
> ported to about every platform out there.  You don't need QT or wxWidgets,
> because the Tk extensions of it already work.

Tcl's popularity is also on the wane.  I don't think hitching CMake's
post to Tcl is a good marketing idea.  I'd pick Ruby, for the regex
support.  Hey it's better 'n' Perl 6.  :-)

>  Many features in the CMake language don't really work the way people
> expect, or are not documented, or both.

I agree that much can be improved about the documentation.  I'd like
to note, however, that some improvements are happening in CVS right
now.  Enough to make me think that Kitware does take documentation
seriously and that strategically, documentation problems are going to
be addressed.  I've given a lot of gloom and doom about documentation,
that if the status quo is maintained, in 3 years' time CMake will
start to lose customers as other build systems catch up in technical
capability.  But I do think 3 years is the level of urgency of the
problem.  We'd all like things right this second, but open source has
its resource limitations.  Recently I suggested organizing Google
Summer Of Code projects to address such things.

>  If anyone would like to fork cmake with me, I'm game.
>
>  Features:
>
>  Tcl frontend featuring modern dynamic language constructs and consistent
> syntax.
>
>  C pre-processor based dependency scanner
>
>  Accurate and up to date documentation
>
>  Focus on getting build system that works, because all of the language
> constructs have already been written.
>
>  Developers who are not hostile to ideas concerning improvements to the
> language.

To make real improvements in all of those areas, you'd need a lot of
funding.  What kind of mandate do you have?  There's not much point in
saying "everything's gonna be better" if you don't have the labor.

Second question, if you do have serious development resources at your
disposal: what improvements in CMake would cause you to stick around
rather than going your own way?  Is a position of compromise possible?


Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] improve the CMake language?

[Juan E. Sanchez]

On Fri, 2 Nov 2007, Brandon Van Every wrote:


On Nov 1, 2007 11:40 PM, Sanchez, Juan <[EMAIL PROTECTED]> wrote:


 Tcl is a simple language, and is well understood.  It has already been
ported to about every platform out there.  You don't need QT or wxWidgets,
because the Tk extensions of it already work.


Tcl's popularity is also on the wane.  I don't think hitching CMake's
post to Tcl is a good marketing idea.  I'd pick Ruby, for the regex
support.  Hey it's better 'n' Perl 6.  :-)


 Many features in the CMake language don't really work the way people
expect, or are not documented, or both.


I agree that much can be improved about the documentation.  I'd like
to note, however, that some improvements are happening in CVS right
now.  Enough to make me think that Kitware does take documentation
seriously and that strategically, documentation problems are going to
be addressed.  I've given a lot of gloom and doom about documentation,
that if the status quo is maintained, in 3 years' time CMake will
start to lose customers as other build systems catch up in technical
capability.  But I do think 3 years is the level of urgency of the
problem.  We'd all like things right this second, but open source has
its resource limitations.  Recently I suggested organizing Google
Summer Of Code projects to address such things.


 If anyone would like to fork cmake with me, I'm game.

 Features:

 Tcl frontend featuring modern dynamic language constructs and consistent
syntax.

 C pre-processor based dependency scanner

 Accurate and up to date documentation

 Focus on getting build system that works, because all of the language
constructs have already been written.

 Developers who are not hostile to ideas concerning improvements to the
language.


To make real improvements in all of those areas, you'd need a lot of
funding.  What kind of mandate do you have?  There's not much point in
saying "everything's gonna be better" if you don't have the labor.

Second question, if you do have serious development resources at your
disposal: what improvements in CMake would cause you to stick around
rather than going your own way?  Is a position of compromise possible?



This would be a community effort.  I don't have the resources to 
strike out on my own.  I like using cmake.  The language is kind of a 
bitter pill for people in my organization to swallow.


The most important item on my proposed feature list is the Tcl 
frontend.


Juan






Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake





Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

RE: [CMake] Adding non .cpp or .h file to a visual studio project.

[Josef Karthauser]

> From: Joshua Jensen [mailto:[EMAIL PROTECTED] 
> Sent: 02 November 2007 15:09
> To: Philip Lowman
> Cc: Josef Karthauser; CMake ML
> Subject: Re: [CMake] Adding non .cpp or .h file to a visual studio project.
>
> Philip Lowman wrote: 
> Josef Karthauser wrote:
>   
> Hi there again,
> I’m using cmake to create some visual studio projects, and want to
> include some non-C files (config.txt for instance) into the vcproj file
> so that my Visual Studio users can edit the file from within the IDE. 
>   I can’t add them using ADD_LIBRARY or ADD_EXECUTABLE, so how do I
> register them?
> > 
>
> This works for me on CMake 2.4.6 and Visual Studio 8:
>
> SET_SOURCE_FILES_PROPERTIES(readme.txt PROPERTIES HEADER_FILE_ONLY true)
> ADD_LIBRARY(foo foo.cc readme.txt)
>   
> I tried it this morning, and I didn't even need the 
> SET_SOURCE_FILES_PROPERTIES.

Sure, but if you do 

ADD_LIBRARY(foo readme.txt)

you get an error.

So how do you create a project which only has non-C objects?

Joe
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Re: INSTALL DIRECTORY broken

[Thomas Sondergaard]

I took a look at the cmake source and I think perhaps this is a bug. The 
FILES mode checks that the specified files are not directories, and I 
think maybe the DIRECTORY mode simply wants to check that the specified 
paths are not regular files?


--- t/cmake-2.4.7/Source/cmInstallCommand.cxx   2007-07-16 
23:12:31.0 +0200
+++ cmake-2.4.7/Source/cmInstallCommand.cxx 2007-11-02 
15:44:53.0 +0100

@@ -958,7 +958,8 @@
 }

   // Make sure the name is a directory.
-  if(!cmSystemTools::FileIsDirectory(dir.c_str()))
+  if(cmSystemTools::FileExists(dir.c_str()) &&
+!cmSystemTools::FileIsDirectory(dir.c_str()))
 {
 cmOStringStream e;
 e << args[0] << " given non-directory \""


Regards,

Thomas

Thomas Sondergaard wrote:

Well, probably not - it's just not doing what I want :-)

I'm using doxygen and want to install the documentation (to make a 
package-doc rpm package). My doc/CMakeLists.txt looks like this:


ADD_CUSTOM_COMMAND(OUTPUT api/index.html COMMAND doxygen Doxyfile)
ADD_CUSTOM_TARGET(doc DEPENDS api/index.html)

INSTALL(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/api DESTINATION 
share/doc/MyPackage/)

INSTALL(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/man DESTINATION share)

The problem is that I will get an error from cmake (not make!):

/u/ts/evz/evbase/doc/CMakeLists.txt:9:
INSTALL DIRECTORY given non-directory "/u/ts/evz/evbase/build/doc/api" 
to install.


Obviously the api directory doesn't exist yet, it will be made when I 
run 'make doc'.


The INSTALL FILES signature doesn't suffer from the same problem.

Regards,

Thomas


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Adding non .cpp or .h file to a visual studio project.

[Joshua Jensen]

Philip Lowman wrote:

Josef Karthauser wrote:
  

Hi there again,
I’m using cmake to create some visual studio projects, and want to
include some non-C files (config.txt for instance) into the vcproj file
so that my Visual Studio users can edit the file from within the IDE. 
  I can’t add them using ADD_LIBRARY or ADD_EXECUTABLE, so how do I

register them?



This works for me on CMake 2.4.6 and Visual Studio 8:

SET_SOURCE_FILES_PROPERTIES(readme.txt PROPERTIES HEADER_FILE_ONLY true)
ADD_LIBRARY(foo foo.cc readme.txt)
  
I tried it this morning, and I didn't even need the 
SET_SOURCE_FILES_PROPERTIES.


Josh
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] improve the CMake language?

[david . karr]

> From: "Eric Noulard" <[EMAIL PROTECTED]>:
> 
> I used Java for 4+ years (all thoses years are overlapping :=)
> it was really pleased using it for cross platform GUI.
> And I was really disappointed because the java I  used
> was lacking generics such that I need to cast here and there when
> using container.

This may be a little off-topic, but generic types were added to Java at
least two years ago.  So, for example, you now can declare an object of
type Vector.  Generic types are also useful for a lot more than
just avoiding casts when getting objects from containers.

> I hope I've already put you on the road of
> "there is no FAR better language than other".

This is an excellent point.  Unlike any specific language feature, this
statement is not likely to be falsified by the language designers at any
time in the near future.

Personally, I find the macros of CMAKE a little awkward at times, but
when I want to do anything more sophisticated, I am very happy to write
a little helper script or program for CMAKE to invoke.  I converted the
build of one of my group's software projects to CMAKE a few years ago
and it's served us very well ever since, though we now have more than
1800 source code files distributed among nearly 50 libraries and
executables.

David Karr

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] improve the CMake language?

[Bill Hoffman]

Sanchez, Juan wrote:

Hello Bill,

add_library(foo SHARED foo.cxx)

won't work.


I meant it worked in the current cmake language, I know it does not work 
in tcl.





Developers who are not hostile to ideas concerning improvements to the 
language.


I am not hostile to ideas about improvements to the language, I am 
hostel to changing to a new language.  The requirements are that we 
don't bring any new major dependencies other than a standard c++ 
compiler.  Also, that we remain backwards compatible.


-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Universal Binary Support on OS X 10.4

[Sean McBride]

On 11/1/07 10:35 AM, Mike Jackson said:

>I am on a MacBook Pro and need to compile for PPC. I launch ccmake
>and set CMAKE_OSX_ARCHITECTURES to ppc. I then generate and then run
>make VERBOSE=1. What gets produced is still an i386 binary though.
>
>If I manually put in -arch ppc into both the c and c++ compile
>flags then I get a ppc build. Is this the way it is supposed to work
>or am I missing something.

You are missing:


It would be great if you could test the CVS CMake, the fix was long to
arrive and fraught with little issues.

--

Sean McBride, B. Eng [EMAIL PROTECTED]
Rogue Researchwww.rogue-research.com
Mac Software Developer  Montréal, Québec, Canada

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] ignoring a specific library

[Philip Lowman]

Mark Wyszomierski wrote:
> Is it possible to add an ignore library to CMakeLists.txt? This is
> specifically for a win32 project. I want to ignore:
> 
> nafxcwd.lib
> libcmtd.lib

Here's how I do this with CMake 2.4.6.  Unfortunately passing more than
one /NODEFAULTLIB arguments was broken in CMake 2.4.7 (see Bug #5455).

In short, use the SET_TARGET_PROPERTIES() with the LINK_FLAGS or
LINK_FLAGS_DEBUG, LINK_FLAGS_RELEASE, etc. options.


SET(VS_MULTITHREADED_DEBUG_DLL_IGNORE_LIBRARY_FLAGS
"/NODEFAULTLIB:libc.lib
 /NODEFAULTLIB:libcmt.lib
 /NODEFAULTLIB:msvcrt.lib
 /NODEFAULTLIB:libcd.lib
 /NODEFAULTLIB:libcmtd.lib"
)
SET(VS_MULTITHREADED_RELEASE_DLL_IGNORE_LIBRARY_FLAGS
"/NODEFAULTLIB:libc.lib
 /NODEFAULTLIB:libcmt.lib
 /NODEFAULTLIB:libcd.lib
 /NODEFAULTLIB:libcmtd.lib
 /NODEFAULTLIB:msvcrtd.lib"
)

IF(MSVC)
 SET_TARGET_PROPERTIES(simulator-static PROPERTIES
LINK_FLAGS_DEBUG
${VS_MULTITHREADED_DEBUG_DLL_IGNORE_LIBRARY_FLAGS})

 SET_TARGET_PROPERTIES(simulator-static PROPERTIES
 LINK_FLAGS_RELWITHDEBINFO
 ${VS_MULTITHREADED_RELEASE_DLL_IGNORE_LIBRARY_FLAGS})
 SET_TARGET_PROPERTIES(simulator-static PROPERTIES
 LINK_FLAGS_RELEASE
 ${VS_MULTITHREADED_RELEASE_DLL_IGNORE_LIBRARY_FLAGS})
 SET_TARGET_PROPERTIES(simulator-static PROPERTIES
 LINK_FLAGS_MINSIZEREL
 ${VS_MULTITHREADED_RELEASE_DLL_IGNORE_LIBRARY_FLAGS})
ENDIF(MSVC)


-- 
Philip Lowman
Sr. Simulation Development Engineer, Modeling and Simulation Technology
General Dynamics Land Systems
http://www.gdls.com
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] INSTALL DIRECTORY broken

[Thomas Sondergaard]

Well, probably not - it's just not doing what I want :-)

I'm using doxygen and want to install the documentation (to make a 
package-doc rpm package). My doc/CMakeLists.txt looks like this:


ADD_CUSTOM_COMMAND(OUTPUT api/index.html COMMAND doxygen Doxyfile)
ADD_CUSTOM_TARGET(doc DEPENDS api/index.html)

INSTALL(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/api DESTINATION 
share/doc/MyPackage/)

INSTALL(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/man DESTINATION share)

The problem is that I will get an error from cmake (not make!):

/u/ts/evz/evbase/doc/CMakeLists.txt:9:
INSTALL DIRECTORY given non-directory "/u/ts/evz/evbase/build/doc/api" 
to install.


Obviously the api directory doesn't exist yet, it will be made when I 
run 'make doc'.


The INSTALL FILES signature doesn't suffer from the same problem.

Regards,

Thomas

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Adding non .cpp or .h file to a visual studio project.

[Philip Lowman]

Josef Karthauser wrote:
> Hi there again,
> I’m using cmake to create some visual studio projects, and want to
> include some non-C files (config.txt for instance) into the vcproj file
> so that my Visual Studio users can edit the file from within the IDE. 
>   I can’t add them using ADD_LIBRARY or ADD_EXECUTABLE, so how do I
> register them?

This works for me on CMake 2.4.6 and Visual Studio 8:

SET_SOURCE_FILES_PROPERTIES(readme.txt PROPERTIES HEADER_FILE_ONLY true)
ADD_LIBRARY(foo foo.cc readme.txt)

-- 
Philip Lowman
Sr. Simulation Development Engineer, Modeling and Simulation Technology
General Dynamics Land Systems
http://www.gdls.com
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] improve the CMake language?

[Bill Hoffman]

Eric Noulard wrote:



CMAKE_LOAD_PLUGIN(TCL)

CMAKE_TCL(IN_VAR a
IN_VAR b
OUT_VAR g
OUT_VAR h
SCRIPT_STRING "")

or

CMAKE_TCL(IN_VAR a
IN_VAR b
OUT_VAR g
OUT_VAR h
SCRIPT_FILE "/path/to/tcl_script.tcl")



You can do that today.  CMake already supports loaded commands via c++ 
plugins. I would not recommend it, execute_process is much safer to use 
(shared library plugins have to match the compiler abi of the running 
cmake 64/32 bit issues can cause problems.)


-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] disabling the cache

[Philip Lowman]

Jesper Eskilson wrote:
> Bill Hoffman wrote:
> 
>> For this case, you could have something like this:
>>
>> # if SOME_PROGRAM has a value but the program has been moved
>> # or removed from the system, then clear the cache entry
>> # so that find_program will try again.
>> if(SOME_PROGRAM AND NOT EXISTS ${SOME_PROGRAM})
>>   set(SOME_PROGRAM NOTFOUND CACHE FORCE "some program")
>> endif(SOME_PROGRAM AND NOT EXISTS ${SOME_PROGRAM})
>> find_program(SOME_PROGRAM myprog)
>>
>> So, if you know that you are changing a cmakelist file in a way that
>> requires something to be removed from the cache, just remove it, but
>> be careful not to remove it all the time.
> 
> Ouch. My cmake files are unreadable enough without an added 3 lines here
> and there checking if the cache entry needs to be replaced or not.
> 
> BTW: Are there any plans of fixing the broken regeneration for Visual
> Studio? Or at least documenting it as known problem? As it is now, the
> project files are regenerated but not reloaded, and there is no feedback
> that the new project files aren't used for the build.
> 

And a related note here is Visual Studio's inability to detect that
preprocessor definitions or dependent libraries have changed in a VCproj
file and rebuild or relink the target accordingly.

I've always wondered if CMake could solve this limitation of Visual
Studio by removing object files and/or generated libraries to
effectively force Visual Studio to rebuild or relink the code using the
new settings.

-- 
Philip Lowman
Sr. Simulation Development Engineer, Modeling and Simulation Technology
General Dynamics Land Systems
http://www.gdls.com

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] ignoring a specific library

[Mark Wyszomierski]

Hi,

Is it possible to add an ignore library to CMakeLists.txt? This is
specifically for a win32 project. I want to ignore:

nafxcwd.lib
libcmtd.lib

Thanks
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] improve the CMake language?

[Gonzalo Garramuño]

Brandon Van Every wrote:


Is it worth trying to address these problems and make CMake a better
scripting language? 


Yes, but currently as a low priority.  CMake first needs to have an 
extremely solid cross-compile toolchain and support as many systems as 
possible first without any major issues.

CMake is already very close to getting there.  I think in a year or so
this will be achieved without major issues.  Already the cmake2.5 
internals and fixes are way better than the 2.4 branch.


At that point it may indeed be worth forking cmake to improve or change
its language.



My concern is that if the status quo is maintained, CMake script will
always be ugly to program with.  


Yes.  No doubt about that.  It is already uglier to program with than
most modern scripting languages.
Personally I think you need to see cmake as what it is: a tool to create
makefiles.  Not a scripting language.  If you are doing lots of file, 
regex or string manipulation... alarms should be going off.  You should 
probably write that as a small tool in ruby, perl or python and have 
cmake just call the command.



This will put it at a disadvantage
compared to build systems written in Python, Ruby, or Perl.  


Perl and TCL -- no.  Perl because of the sygils and bad OO.  TCL due to 
bad OO, brackets and weak regex.


Ruby?  Certainly.  Its metalanguage allows for the creation of a next 
generation make system.  But nobody is, afaik, actually working on one. 
 Most rubyists are happy with rake, which is only a very simple make 
system and does not take full advantage of ruby meta language strengths.


Python?  Probably, but use of parenthesis still remains more cumbersome 
than what it should be (not as bad as cmake, thou).


I do agree that sooner or later, the cmake macro language will become a 
disadvantage ( how soon?  who knows--- I give it 3 to 5 years or even 
more ).


The syntax of the language also will only matter when something matches 
cmake's features first.  In the short run, I'm unaware of anything that 
will be successful at this.


Currently all competing open source build systems are inferior feature
wise to cmake.  And cmake has had a lot more tuning in terms of properly
setting compiler flags than any other build system I've used.

Build systems built on top of scripting languages also suffer from being 
a tad bloated.  Unless you plan to use the scripting language later for 
something else, you end up installing tons of libs the build system 
probably never uses (networking, web, ssh, ftp, etc).


Another issue with other popular systems built on scripting languages is
that they usually try to replace not just a tool like 'cmake' or
'autotools' but they replace 'make' also.  Which is a neat idea, but 
also a potential mistake.  This often makes troubleshooting build 
problems harder, as the build systems internals are often not as well 
documented as the api.  One of the big strengths of cmake is that both 
the modules and the C++ is very readable.
When you replace make, developers only familiar with IDEs are completely 
left out, unlike a tool like cmake.


Another issue with scons, rake, etc. are that they are still slower than
cmake's approach.  For small projects, that may not matter, but today on 
large projects you still can notice.  Even a difference of 10 seconds 
adds up to a lot when you consider the hundreds of iterations a C/C++ 
project has to go through to reach a stable state.


The last headache with a build system built on top of a scripting
language is that as soon as a better language appears, the build system
may need to be rewritten or thrown out.

CMake may indeed eventually need to replace its macro language, but all 
the C++ core and platform specific stuff can always remain regardless of 
the user front-end.  And thankfully, cmake's internals are really very 
clean C++ code, so I am confident that even if Kitware were to refuse 
changing their language once lots of people start feeling the need for 
doing so, someone else can step up to the challenge.


> I'm not just talking about SCons and so forth.

python scons, ruby's rake and jam are (currently) cmake's closest 
contenders.  But they are not good or comprehensive enough to 
distinguish themselves (yet, at least).
Python gives you a better language overall, but its syntax also gets in 
the way when writing rules.  Rake is usually better, but it is a very 
barebones make system (think cmake sans modules).



we'll write our own
custom build system in our favorite scripting language.  It happens in
the game industry all the time.



Does it?  I work in a related industry and I never heard of such.  Only
very large companies can afford that kind of luxury.

There usually is not enough time to create your build system.  And the
last thing you want is to then have to keep maintaining that build
system, which is something 5 to 30 developers will use and must always work.

That being said, the gaming industry is also mostly orie

Re: [CMake] improve the CMake language?

[Eric Noulard]

2007/11/2, David Cole <[EMAIL PROTECTED]>:
> Existing CMake "plugin" :
> EXECUTE_PROCESS(COMMAND tclsh "$ENV{HOME}/myTclScript.tcl" OUTPUT_VARIABLE
> ov RESULT_VARIABLE rv)

Yes you are right I can do that.

> You are responsible for making sure tclsh is callable for your project's
> users...

That why I would tell explicitly I want to use TCL/python...
CMAKE_LOAD_PLUGIN(TCL)

But again I may do it with some CMake MACRO.

>
> Because there is such diversity out there and people have so many varied
> opinions of which language would be ideal to use, CMake *already provides*
> the ability to shell out to any script processor you would like.

I agree on this, no single language may suits everyone's need or taste.

> CMake's -P scripting ability is actually quite powerful for what it is right
> now, though with its own quirks, and incremental improvements are bound to
> come over time, but...

Regarding CMake scripting you end-up with the choice
of adding Feature to CMake or decide it's better to escape to
perl,python, tcl ...

> ...in the mean time, just use whatever scripting languauge you want. Make
> macros that demonstrate how to run scripts at configure time and at build
> time with your favorite script processor and submit them to the Wiki for
> others to benefit from if you feel so inclined.

OK I will do that.

-- 
Erk
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Adding non .cpp or .h file to a visual studio project.

[Josef Karthauser]

Hi there again,

 

I'm using cmake to create some visual studio projects, and want to
include some non-C files (config.txt for instance) into the vcproj file
so that my Visual Studio users can edit the file from within the IDE.
I can't add them using ADD_LIBRARY or ADD_EXECUTABLE, so how do I
register them?

 

Does anyone know?

 

Thanks,

Joe

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] improve the CMake language?

[David Cole]

Existing CMake "plugin" :
EXECUTE_PROCESS(COMMAND tclsh "$ENV{HOME}/myTclScript.tcl" OUTPUT_VARIABLE
ov RESULT_VARIABLE rv)

You are responsible for making sure tclsh is callable for your project's
users...
Similarly for python, ruby, perl, shell script, or *whatever*
Or, if you want it done as part of the build, same command line but with
ADD_CUSTOM_COMMAND...

Because there is such diversity out there and people have so many varied
opinions of which language would be ideal to use, CMake *already provides*
the ability to shell out to any script processor you would like.

CMake's -P scripting ability is actually quite powerful for what it is right
now, though with its own quirks, and incremental improvements are bound to
come over time, but...

...in the mean time, just use whatever scripting languauge you want. Make
macros that demonstrate how to run scripts at configure time and at build
time with your favorite script processor and submit them to the Wiki for
others to benefit from if you feel so inclined.


2 cents,
David


On 11/2/07, Eric Noulard <[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> I'm interested in the idea of a "more powerful" CMake scripting.
> I'm convinced I lack powerful scripting sometimes (may be many times)
> but my opinion is it's not CMake's script job.
>
> 2007/11/2, Sanchez, Juan <[EMAIL PROTECTED]>:
> >
> >  Tcl is a simple language, and is well understood.  It has already been
> > ported to about every platform out there.  You don't need QT or
> wxWidgets,
> > because the Tk extensions of it already work.
>
> I did some Tcl, Perl and Python.
> Tcl syntax is really awkward at first sight.
> You get used to it but not as fast Python.
> I did some 7 years of Fortran programming (mostly F77 and F90)
> then 10+ years of C++.
> Fortran is far better than C++ for many things.
> The converse is true too :=)
> I used Java for 4+ years (all thoses years are overlapping :=)
> it was really pleased using it for cross platform GUI.
> And I was really disappointed because the java I  used
> was lacking generics such that I need to cast here and there when
> using container.
>
> I hope I've already put you on the road of
> "there is no FAR better language than other".
>
> Personally if I were to extend or re-implement CMake
> scripts I'll do it in Python because I _currently_
> find it far more powerful than Tcl and pretty widespread too.
> (I had even looked at SCons for this reason before using CMake).
>
> But the fact is I don't think I _NEED_ a python
> implementation of CMake but may be I would like
> a "Python plugin" (or Tcl or Ruby or ...) for CMake.
>
> This way we can keep the CMake scripting language
> small and bug free (someday) and take the "Python plugin"
> escape door when needed.
>
> >  Many features in the CMake language don't really work the way people
> > expect, or are not documented, or both.
>
> Documentation is not as good as it should be
> but re-implementing something (either TCL, Python, Perl)
> won't make the documentation better.
>
> I know you'll inherit a clean syntax definition
> (iff you ever chose python :=) but you won't get
> the "up to date" documentation for your freshly
> implemented functions.
>
> As for bug I'm sure you know that fresh new software
> usually have many more bugs than old one.
>
> >  If anyone would like to fork cmake with me, I'm game.
> >
> >  Features:
> >
> >  Tcl frontend featuring modern dynamic language constructs and
> consistent
> > syntax.
> >
> >  C pre-processor based dependency scanner
> >
> >  Accurate and up to date documentation
> >
> >  Focus on getting build system that works, because all of the language
> > constructs have already been written.
> >
> >  Developers who are not hostile to ideas concerning improvements to the
> > language.
>
> I am convinced of the usefullness of improvement of the language
> but I'm not convinced that a fork is the way to go.
>
> What would you think of
>
> CMAKE_LOAD_PLUGIN(TCL)
>
> CMAKE_TCL(IN_VAR a
> IN_VAR b
> OUT_VAR g
> OUT_VAR h
> SCRIPT_STRING "")
>
> or
>
> CMAKE_TCL(IN_VAR a
> IN_VAR b
> OUT_VAR g
> OUT_VAR h
> SCRIPT_FILE "/path/to/tcl_script.tcl")
>
> In both cases you can run Tcl code from within CMake scripts
> you give IN_VAR and you get OUT_VAR.
>
> All this is my own opinion though :=)
> --
> Erk
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

RE: [CMake] Building linux kernel module with Cmake

[Suhas Jain]

As you said I am using these ADD_CUSTOM_COMMAND / ADD_CUSTOM_TARGET
But its not working at my end... please help me out
This is what I have in my CMakeLists.txt file
===
Set( MODULE_OUTPUT_FILEShello.o
hello.mod.c
hello.mod.o
hello.ko
.hello.o.cmd
.hello.ko.cmd
.hello.mod.o.cmd
main.o
.main.o.cmd
output.o
output.o.cmd
.tmp_versions/hello.mod
.tmp_versions/ )

Set( MODULE_SOURCE_FILESoutput.c 
main.c )

Set( DRIVER_FILEhello.ko )
Set( DRIVER_TARGET_NAME hello-module )
Set( DRIVER_BIN_FILE${CMAKE_BINARY_DIR}/bin/${DRIVER_FILE} )
Set( MODULE_SOURCE_DIR  ${CMAKE_CURRENT_BINARY_DIR} )

Set( KERNEL_DIR "/lib/modules/2.6.20-16-generic/build" )
Set( KBUILD_CMD ${CMAKE_MAKE_PROGRAM}
-C ${KERNEL_DIR}
M=${MODULE_SOURCE_DIR}
modules )
=

Please point me out if I am doing something wrong. I think I am missing
something to add.




-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Brandon Van
Every
Sent: Friday, November 02, 2007 12:08 AM
To: cmake@cmake.org
Subject: Re: [CMake] Building linux kernel module with Cmake

On Nov 1, 2007 5:48 AM, Suhas Jain <[EMAIL PROTECTED]> wrote:
> Thanks for you reply Hendrik
> Even I know that Kbuild is a very simple procedure to do so.
> But I have a source tree which has applications, drivers and other modules
> for different OS as well as hardware architectures and I want to compile
all
> these folders from a single top level directory. All this can be achieved
> with Cmake utlity. I have already compiled other modules.
> I want to know if it possible to use cmake for compiling kernel module

It would be simpler to use ADD_CUSTOM_COMMAND / ADD_CUSTOM_TARGET to
invoke the Linux kernel's native Kbuild, then utilize the results.


Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake



___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] improve the CMake language?

[Eric Noulard]

Hi all,

I'm interested in the idea of a "more powerful" CMake scripting.
I'm convinced I lack powerful scripting sometimes (may be many times)
but my opinion is it's not CMake's script job.

2007/11/2, Sanchez, Juan <[EMAIL PROTECTED]>:
>
>  Tcl is a simple language, and is well understood.  It has already been
> ported to about every platform out there.  You don't need QT or wxWidgets,
> because the Tk extensions of it already work.

I did some Tcl, Perl and Python.
Tcl syntax is really awkward at first sight.
You get used to it but not as fast Python.
I did some 7 years of Fortran programming (mostly F77 and F90)
then 10+ years of C++.
Fortran is far better than C++ for many things.
The converse is true too :=)
I used Java for 4+ years (all thoses years are overlapping :=)
it was really pleased using it for cross platform GUI.
And I was really disappointed because the java I  used
was lacking generics such that I need to cast here and there when
using container.

I hope I've already put you on the road of
"there is no FAR better language than other".

Personally if I were to extend or re-implement CMake
scripts I'll do it in Python because I _currently_
find it far more powerful than Tcl and pretty widespread too.
(I had even looked at SCons for this reason before using CMake).

But the fact is I don't think I _NEED_ a python
implementation of CMake but may be I would like
a "Python plugin" (or Tcl or Ruby or ...) for CMake.

This way we can keep the CMake scripting language
small and bug free (someday) and take the "Python plugin"
escape door when needed.

>  Many features in the CMake language don't really work the way people
> expect, or are not documented, or both.

Documentation is not as good as it should be
but re-implementing something (either TCL, Python, Perl)
won't make the documentation better.

I know you'll inherit a clean syntax definition
(iff you ever chose python :=) but you won't get
the "up to date" documentation for your freshly
implemented functions.

As for bug I'm sure you know that fresh new software
usually have many more bugs than old one.

>  If anyone would like to fork cmake with me, I'm game.
>
>  Features:
>
>  Tcl frontend featuring modern dynamic language constructs and consistent
> syntax.
>
>  C pre-processor based dependency scanner
>
>  Accurate and up to date documentation
>
>  Focus on getting build system that works, because all of the language
> constructs have already been written.
>
>  Developers who are not hostile to ideas concerning improvements to the
> language.

I am convinced of the usefullness of improvement of the language
but I'm not convinced that a fork is the way to go.

What would you think of

CMAKE_LOAD_PLUGIN(TCL)

CMAKE_TCL(IN_VAR a
IN_VAR b
OUT_VAR g
OUT_VAR h
SCRIPT_STRING "")

or

CMAKE_TCL(IN_VAR a
IN_VAR b
OUT_VAR g
OUT_VAR h
SCRIPT_FILE "/path/to/tcl_script.tcl")

In both cases you can run Tcl code from within CMake scripts
you give IN_VAR and you get OUT_VAR.

All this is my own opinion though :=)
-- 
Erk
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Symbian support

[Salvatore Iovene]

Hello,
are there any plans for supporting the symbian platform? I.e. having
CMake generate the build files for Symbian.

If not, could you give me some estimates about how hard a job it'd be?

Thank you!



-- 
Salvatore Iovene
http://www.iovene.com/
Key Fingerprint: 5647 944D D5AD 2E87 00B4  7D54 2864 359D FF20 16D8
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Accurate package_source

[Eric Noulard]

2007/11/2, Thomas Sondergaard <[EMAIL PROTECTED]>:
> It seems that package_source just packs the source directory. I'd like
> it to work like autotools make DIST, ie it packs the source files plus
> whatever is put in EXTRA_DIST.

I remember the pros/cons of cpack
(the command used when "make package_source" is called)
was already discussed on the list.

May be you can search the ML archive:
http://www.cmake.org/pipermail/cmake/

>
> How can I do that?
>

I'm not actively using autotools since a while but
I think "make dist" precisely DOES NOT package all the source
but only the file included in some automake rules.

http://www.gnu.org/software/automake/manual/automake.html#Dist

With CPack the control of what is packaged and what
is not is more "basic"

take all the file in the source tree
minus those which match the content
CPACK_SOURCE_IGNORE_FILES

I usually use:
SET(CPACK_SOURCE_IGNORE_FILES
"/CVS/;/.svn/;.swp$;.#;/#;.*~;cscope.*")

I you want to include generated files (which are in the build tree)
I don't know if it's possible to do it without putting the generated
file in the source tree.

-- 
Erk
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

RE: [CMake] Make clean - doesn't clean dependencies.

[Josef Karthauser]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: 01 November 2007 23:09
> To: Josef Karthauser; CMake ML
> Subject: Re: [CMake] Make clean - doesn't clean dependencies.
> 
> Josef Karthauser wrote:
> > It doesn't appear that a 'make clean' in a subdirectory of the build
> > tree cleans any of the dependencies.  Does anyone know of a way that
> it
> > can be persuaded to?
> >
> 
> make depend
> 
> For more info, cmake creates: make help
> 

You don't appear to have understood what I was asking.  I was talking
about clean, not depend.

Joe
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Accurate package_source

[Thomas Sondergaard]

It seems that package_source just packs the source directory. I'd like 
it to work like autotools make DIST, ie it packs the source files plus 
whatever is put in EXTRA_DIST.


How can I do that?

Regards,

Thomas

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake