Thank you Philip, I will have a look at it.
Regards,
Olivier
Philip Lowman a écrit :
Olivier Tournaire wrote:
Sorry, I made a mistake in my previous mail. In fact, I would like to
have this :
Project__
|
|___ Header Files__
|
On Sunday 24 February 2008 23:22:58 blinkeye wrote:
On 2/24/08, David Sveningsson [EMAIL PROTECTED] wrote:
Hi, I'm quite new with cmake and I can't figure out how to enable
warnings for the generated makefiles/projects. For instance, I would
like to use the -Wall flag with gcc.
like
Hi, I searched for an answer to this question in vain, so I'm asking here.
I am trying to build a library wich is spead among many subdirectories using
CMake, but I can't seem to do it the Right Way.
Looks like the right way to do this would be to write a CMakeLists.txt in
each subdirectory, as
packadal wrote:
Looks like the right way to do this would be to write a CMakeLists.txt
in each subdirectory, as this would be cleaner, and much more
changes-friendly, but I can't seem to build only one library when I do
it this way.
example of my source tree :
+ src
| - Application
| -
On Mon, February 25, 2008 11:11, dizzy wrote:
On Sunday 24 February 2008 23:22:58 blinkeye wrote:
On 2/24/08, David Sveningsson [EMAIL PROTECTED] wrote:
Hi, I'm quite new with cmake and I can't figure out how to enable
warnings for the generated makefiles/projects. For instance, I would
Hello,
On 2/25/08, packadal [EMAIL PROTECTED] wrote:
Hi, I searched for an answer to this question in vain, so I'm asking here.
I am trying to build a library wich is spead among many subdirectories using
CMake, but I can't seem to do it the Right Way.
Looks like the right way to do this
Thanks for the fast answers :)
I can't seem to use this solution, as i have different files that I include
or not, depending on the platform.
So i guess the good way would be to link all this together.
Here's where I'm stuck :
I try to use TARGET_LINK_LIBRARIES to in the darkness bind them
Thanks for the fast answers :)
I can't seem to use this solution, as i have different files that I include
or not, depending on the platform.
So i guess the good way would be to link all this together.
Here's where I'm stuck :
I try to use TARGET_LINK_LIBRARIES to in the darkness bind them
In principle CMake implements two thing,
- a scripting language,
- and a make/build-file generator.
As I understand it, these two things are currently
mixed up in CMakeLib: all commands parse the arguments
(scripting functionality) and then call the generator
function with the
Hi,
Me and a work friend ran into the same problem a few days ago. May I suggest
to the admins to add a little note in the IF doc about this common mistake ?
Regards,
--
Mehdi
On Fri, Feb 22, 2008 at 4:08 PM, Fernando Cacciola
[EMAIL PROTECTED] wrote:
Sylvain Benner wrote:
Now, why didn't
On Mon, Feb 25, 2008 at 10:16 AM, Mehdi Rabah [EMAIL PROTECTED] wrote:
Hi,
Me and a work friend ran into the same problem a few days ago. May I suggest
to the admins to add a little note in the IF doc about this common mistake ?
Generally best to file such suggestions in the bug tracker as
The other is that a non-trivial portion of CMake is written in the scripting
language ala the Modules directory. So supporting multiple languages becomes
problematic. Most languages are not designed to mix with other languages. I
doubt you can mix python and Lua and expect them to be able to
Hi all,
I've encountered a problem generating RPMs with the latest
CVS: apparently, some versions of rpmbuild (ours is 4.2.2) do
the pre-processing even when the variable to replace is inside
commentaries.
In CPackRPM.cmake, the %install directive is found twice (lines 192 and
198), thus
On Sunday 24 February 2008, Yang Zhang wrote:
Hendrik Sattler wrote:
Am Sonntag 24 Februar 2008 schrieb Yang Zhang:
I understand your point, but support for cmake is not as ubiquitous as
it is for autotools. For instance, a cross-platform build system I'm
using (a bitbake/openembedded
On Sunday 24 February 2008, Yang Zhang wrote:
...
$ CPATH=inc make
[100%] Built target a
$ touch inc/a.h
$ CPATH=inc make
[100%] Built target a
It appears that cmake doesn't know where the header files are actually
located, and hence is unable to add a proper dependency.
On Saturday 23 February 2008, Yang Zhang wrote:
Hi, I just finished reading the example in the documentation on the
...
- Can cmake auto-infer libraries based on #includes + a DB of
header-to-library mappings?
No, and I would consider this too much magic.
It should be obvious from the build
Has anyone started support for creating libraries written in delphi/pascal
before? If not completed, something unfinished I could extend, perhaps?
--
Boudewijn Rempt
http://www.valdyas.org/fading/index.cgi
___
CMake mailing list
CMake@cmake.org
On Monday 25 February 2008, dizzy wrote:
On Sunday 24 February 2008 23:22:58 blinkeye wrote:
On 2/24/08, David Sveningsson [EMAIL PROTECTED] wrote:
Hi, I'm quite new with cmake and I can't figure out how to enable
warnings for the generated makefiles/projects. For instance, I would
On Saturday 23 February 2008, Peter Kümmel wrote:
Hi Ken,
this is a reply to your email on the Lua list:
http://marc.info/?l=lua-lm=120275861422593w=2
It is nice to see that there is interest in Lua as
alternative scripting language. Since I've discovered
Lua I thought it would be a nice
On Monday 25 February 2008, Boudewijn Rempt wrote:
Has anyone started support for creating libraries written in delphi/pascal
before? If not completed, something unfinished I could extend, perhaps?
Not that I know of.
The first step would be to find the compiler etc., i.e. to enable the
Alexander Neundorf wrote:
On Saturday 23 February 2008, Peter Kümmel wrote:
Hi Ken,
this is a reply to your email on the Lua list:
http://marc.info/?l=lua-lm=120275861422593w=2
It is nice to see that there is interest in Lua as
alternative scripting language. Since I've discovered
Lua I
On Mon, Feb 25, 2008 at 2:06 PM, Alexander Neundorf
[EMAIL PROTECTED] wrote:
After having seen some presentations at FOSDEM, I'm even more convinced that
having only limited programming functionality available in build files is a
good thing.
What in particular confirmed this opinion of
Ken Martin wrote:
In VTK and ITK we did design a language independent toolkit and wrapped it
into Tcl, Python, Java etc so we have done that and have a good feel for it.
But for CMake I do not think it is a good idea for a couple reasons. One is
fragmentation of the community/support.
Every
On Monday 25 February 2008, Frederik Deweerdt wrote:
Hi all,
I've encountered a problem generating RPMs with the latest
CVS: apparently, some versions of rpmbuild (ours is 4.2.2) do
the pre-processing even when the variable to replace is inside
commentaries.
In CPackRPM.cmake, the %install
On Monday 25 February 2008, Brandon Van Every wrote:
On Mon, Feb 25, 2008 at 2:06 PM, Alexander Neundorf
[EMAIL PROTECTED] wrote:
After having seen some presentations at FOSDEM, I'm even more convinced
that having only limited programming functionality available in build
files is a good
On Friday 22 February 2008, Jörg Becker wrote:
On Wednesday, 20. February 2008 19:01:55 Alexander Neundorf wrote:
Use:
set_target_properties(hello PROPERTIES INSTALL_RPATH . )
This doesn't work, too. The problem may be, that I don't understand the
path expansion in cmake (or it is buggy).
Alexander Neundorf escreveu:
The build system should provide what you need without requiring that you
actually need to program something.
I think this statement is true regarding the most common building use
cases. But the build system should not limit what you can do in more
elaborate
On Mon, Feb 25, 2008 at 2:22 PM, Peter Kümmel [EMAIL PROTECTED] wrote:
Then it is only possible to provide a C++ interface so that all the
module stuff works behind the scene (behind the interface), using one
scripting language only. And if a new module should go upstream it
must use this
Brandon Van Every wrote:
On Mon, Feb 25, 2008 at 2:22 PM, Peter Kümmel [EMAIL PROTECTED] wrote:
Then it is only possible to provide a C++ interface so that all the
module stuff works behind the scene (behind the interface), using one
scripting language only. And if a new module should go
Quoting Peter Kümmel [EMAIL PROTECTED]:
Ken Martin wrote:
In VTK and ITK we did design a language independent toolkit and wrapped it
into Tcl, Python, Java etc so we have done that and have a good feel for it.
But for CMake I do not think it is a good idea for a couple reasons. One is
Pau Garcia i Quiles wrote:
One Language to rule them all, One Language to find them, One Language
to bring them all and in the compiler bind them.
Nice, but wasn't the One destroyed? ;)
Peter
___
CMake mailing list
CMake@cmake.org
On Mon, Feb 25, 2008 at 2:50 PM, Rodolfo Schulz de Lima
[EMAIL PROTECTED] wrote:
Alexander Neundorf escreveu:
The build system should provide what you need without requiring that you
actually need to program something.
I think this statement is true regarding the most common building use
On Mon, Feb 25, 2008 at 3:14 PM, Peter Kümmel [EMAIL PROTECTED] wrote:
Pau Garcia i Quiles wrote:
One Language to rule them all, One Language to find them, One Language
to bring them all and in the compiler bind them.
Nice, but wasn't the One destroyed? ;)
Actually, all of the rings
On 2008-02-25 11:53+0100 BlinkEye wrote:
On Mon, February 25, 2008 11:11, dizzy wrote:
That looks fairly unportable (how do you make sure your compiler supports
those flags? if it doesn't it won't compile at all which is not probably what
you want since you are using cmake I supose you want it
I'm even more convinced that
having only limited programming functionality available in build files is
a
good thing.
While the cmake language may not be beautiful, it works, and the users
(developers) are not supposed to write programs with it.
OMG flame war Bring it! :)
Seriously
Brandon Van Every wrote:
Actually, all of the rings lost their power at that time.
Analogously, we'd forget about build systems and go into the West.
We could speculate about who's the Dark Lord. By my demeanor I am
surely an Uruk-hai captain. -)
Good closing words for this thread.
See you
I have testing CMake as my build system for medium sized proyects and i
view that change to a tiny scripting instead of CMake macros can be good.
For example in my project. i need stuff for compile other things that are
not out of the box supported by CMake, for example antltr files for generate
On Monday 25 February 2008, Ken Martin wrote:
...
OMG flame war Bring it! :)
How about: everybody should use Ruby, because all other languages suck ! ;-)
Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
On Mon, Feb 25, 2008 at 5:14 PM, Alexander Neundorf
[EMAIL PROTECTED] wrote:
On Monday 25 February 2008, Ken Martin wrote:
...
OMG flame war Bring it! :)
How about: everybody should use Ruby, because all other languages suck ! ;-)
Ruby's license sucks. The price of Ruby's nice
Ken Martin wrote:
Which is why CMake has
include, macro, foreach etc. which are all staples of a programming
language.
Right, much better to spend time on something else, and use Lua for all
these things.
Add wxLua , and the graphical interface becomes easy too. CMakeSetup is
nice, but i
On Mon, Feb 25, 2008 at 5:15 PM, klaas.holwerda [EMAIL PROTECTED] wrote:
Ken Martin wrote:
Which is why CMake has
include, macro, foreach etc. which are all staples of a programming
language.
Right, much better to spend time on something else, and use Lua for all
these things.
Ken Martin wrote:
other's variables out of the box. But with the Modules directory we either
have to have a copy of each module for every possible scripting language, on
the fly converters between any two scripting languages, or something like
that to make it work. Trying to figure out how to
On Tue, Feb 26, 2008 at 2:12 AM, James Mansion
[EMAIL PROTECTED] wrote:
Ken Martin wrote:
other's variables out of the box. But with the Modules directory we either
have to have a copy of each module for every possible scripting language,
on
the fly converters between any two scripting
43 matches
Mail list logo
