On Nov 28, 2007 2:47 AM, Pau Garcia i Quiles [EMAIL PROTECTED] wrote:
As DSL based on Lua != Lua, assuming Kitware gets rid of
documentation and bugs in the language might be too optimistic. Look
for example at RHDL (http://rhdl.rubyforge.org/): it's a Ruby-based
DSL for hardware description,
(Aside: what's with the cm_ prefix?)
The cm_ prefix was something Ken put in his demo. I assumed he was
trying to 'namespace' the thing. I personally like the idea and really
think it should have been applied to the regular CMake language. Often
when I have to read other people's code, I can't
Is backward compatibility with the current language a goal of the LUA
experiment? I ask because the examples spoken of on this list appear to be
trying to mimic the current CMake syntax.
Right now I think it's just an experiment to see how things might
work, how much effort would be involved,
I'd also like a shorter way to dereference a table than
unpack(table).
Seriously, this is a total non-issue and unpack is totally unnecessary.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Quoting Brandon Van Every [EMAIL PROTECTED]:
Talking about Ruby, could someone please paste his wishlist about
variable scoping for CMake? (ie what would you like to add: local
variables which die when you exit the loop, file-scoped variables,
directory-scoped variables, project-scoped
On Nov 28, 2007 3:13 AM, E. Wing [EMAIL PROTECTED] wrote:
(Aside: what's with the cm_ prefix?)
Often
when I have to read other people's code, I can't distinguish between
the 'official' API functions are and the userland functions when I do
not know the official API very well.
Yeah but
On Nov 28, 2007 3:59 AM, Brandon Van Every [EMAIL PROTECTED] wrote:
For any given CMake function, we know what argument types we expect.
The programmer is responsible for dereferencing, we're not going to do
it for them. We just have to parse the keywords like STATIC, and pay
attention to
On Nov 28, 2007 3:17 AM, E. Wing [EMAIL PROTECTED] wrote:
Right now I think it's just an experiment to see how things might
work, how much effort would be involved, and how much of an impedance
mismatch there will be with how things are currently done. It sounds
like things may not progress
On Nov 28, 2007 3:40 AM, Pau Garcia i Quiles [EMAIL PROTECTED] wrote:
Do you mean these threads?
http://www.cmake.org/pipermail/cmake/2005-March/006235.html
http://www.cmake.org/pipermail/cmake/2005-June/006725.html
These are not the threads you're looking for.
If you are talking about a
On Nov 28, 2007 3:20 AM, E. Wing [EMAIL PROTECTED] wrote:
I'd also like a shorter way to dereference a table than
unpack(table).
Seriously, this is a total non-issue and unpack is totally unnecessary.
The argument evaluation model matters.
Cheers,
Brandon Van Every
You need to know the names of the files that will be generated and
then INSTALL(FILES ...)
Typically I just have a hardwired list of root words, from which I
derive .cxx .hxx and whatever a doxygen suffix is. Here are some
helper routines. You're probably also going to want an
ADD_CUSTOM_COMMAND
Quoting Brandon Van Every [EMAIL PROTECTED]:
On Nov 28, 2007 3:40 AM, Pau Garcia i Quiles [EMAIL PROTECTED] wrote:
Do you mean these threads?
http://www.cmake.org/pipermail/cmake/2005-March/006235.html
http://www.cmake.org/pipermail/cmake/2005-June/006725.html
These are not the threads
Am Mittwoch, 28. November 2007 10:38:20 schrieb Brandon Van Every:
You need to know the names of the files that will be generated and
then INSTALL(FILES ...)
Typically I just have a hardwired list of root words, from which I
derive .cxx .hxx and whatever a doxygen suffix is. Here are some
I would think:
INSTALL(DIRECTORY )
would do it in one command without knowledge of the sub-structure of the
directory.
Is there something wrong with that approach?
It should be less error prone than gathering knowledge of doxygen output
just for specifying a bunch of install rules that
I've got a library which I want to build from a target which has a
different name. Is there any way of doing this?
If I do,
ADD_LIBRARY(Foo source.cpp)
this creates a target called 'Foo' which builds 'Foo.lib'. However I
want the library 'Foo.lib' to be built from a target call
cmake --help-command SET_TARGET_PROPERTIES
and read about the OUTPUT_NAME target property...
HTH,
David
On 11/28/07, Josef Karthauser [EMAIL PROTECTED] wrote:
I've got a library which I want to build from a target which has a
different name. Is there any way of doing this?
If I do,
Hi Josef,
try this:
add_library(Foo.Code source.cpp)
set_target_properties(Foo.Code PROPERTIES OUTPUT_NAME Foo)
It should create a target Foo.Code building a library Foo.lib.
Best regards, Gerhard
-Ursprüngliche Nachricht-
Gesendet: Mittwoch, 28. November 2007 13:53
An:
Ya know, if we took all the energy and time that has gone into
debating this issue and instead focused it on CMake dev we might
solve some problems a bit quicker.
Mike
___
CMake mailing list
CMake@cmake.org
On Nov 27, 2007, at 3:55 PM, Luigi CALORI wrote:
I encoundered the same problems and in the end used the horrible
hack to use a file where
append, clear it in the main file.
I think I saw a thread about this. Good to know in the future.
I did figure out a solution without involving a
Has anyone started a QtAssistant version of the CMake Docs? I was
thinking of spending some time trying a few things but I don't want
to start something that is already done, or at least farther along
than I am..
I built the cvs cmake this morning and nothing really jumped out at
me as
I hand made a simple .adp file (attached) for the Qt assistant the other
day, as an experiment.
Ideally, it would be generated based on sections and/or commands in the
html file, and done in the CMakeLists.txt file.
Do you want to pick up where I left off?
Clint
Mike Jackson wrote:
Has
Hi,
I'm currently trying to build a project organized in subdirectories.
In all the subdirectories, several files are generated at build time
(with an ADD_CUSTOM_COMMAND).
In all the directories, a custom target depending on all the files
generated in the subdirectory is created with
On Nov 28, 2007 9:39 AM, Mike Jackson [EMAIL PROTECTED] wrote:
Ya know, if we took all the energy and time that has gone into
debating this issue and instead focused it on CMake dev we might
solve some problems a bit quicker.
Not really. In terms of my personal energy, it was absolutely
Le 28 nov. 07 à 17:35, Gaëtan Lehmann a écrit :
Hi,
I'm currently trying to build a project organized in
subdirectories. In all the subdirectories, several files are
generated at build time (with an ADD_CUSTOM_COMMAND).
In all the directories, a custom target depending on all the files
On Nov 28, 2007 6:45 AM, Stefan Kögl [EMAIL PROTECTED] wrote:
Am Mittwoch, 28. November 2007 10:38:20 schrieb Brandon Van Every:
You need to know the names of the files that will be generated and
then INSTALL(FILES ...)
Typically I just have a hardwired list of root words, from which I
Hello,
I just saw the CMake native command qt_wrap_cpp in cmQTWrapCPPCommand.h.
Why would there be a command like this and a macro in FindQt4
(QT4_WRAP_CPP)? Which is the correct one to use?
I think that these commands might obsolete the patch in this thread
and it should rather be supported in
On Wednesday 28 November 2007, Brandon Van Every wrote:
On Nov 28, 2007 3:17 AM, E. Wing [EMAIL PROTECTED] wrote:
Right now I think it's just an experiment to see how things might
work, how much effort would be involved, and how much of an impedance
mismatch there will be with how things
On Wednesday 28 November 2007, Mike Jackson wrote:
Has anyone started a QtAssistant version of the CMake Docs? I was
thinking of spending some time trying a few things but I don't want
to start something that is already done, or at least farther along
than I am..
I built the cvs cmake this
Erik Johansson wrote:
2007/11/27, James Bigler [EMAIL PROTECTED]:
I got a hint that I could do this to set values that could be read by
the CMakeLists.txt file above:
You can also use get_directory_property. See for example how we use it
in Licq [1] to get a the list of files from a
The following shell script is a hack that I created to generate a
rough set of Docs that can be viewed/searched using QtAssistant from
Qt4. There are probably some bugs in the script but it seems to
generate ok on my system. Also, checking the HTML against BBEdit's
HTML validator, there
2007/11/28, Alexander Neundorf [EMAIL PROTECTED]:
On Wednesday 28 November 2007, Mike Jackson wrote:
Has anyone started a QtAssistant version of the CMake Docs? I was
thinking of spending some time trying a few things but I don't want
to start something that is already done, or at least
2007/11/27, James Bigler [EMAIL PROTECTED]:
I got a hint that I could do this to set values that could be read by
the CMakeLists.txt file above:
You can also use get_directory_property. See for example how we use it
in Licq [1] to get a the list of files from a subdirectory (to
implement
Mike Jackson wrote:
The current (as of
11/28/2007 CMake cvs will NOT generate the module html files. I get a
seg fault) so I switch to the cmake 2.4.7 part way through to at least
What command line did you use to get the seg fault, I can not reproduce
the problem.
-Bill
On Nov 28, 2007 1:28 PM, Alexander Neundorf [EMAIL PROTECTED] wrote:
On Wednesday 28 November 2007, Brandon Van Every wrote:
On Nov 28, 2007 3:17 AM, E. Wing [EMAIL PROTECTED] wrote:
Right now I think it's just an experiment to see how things might
work, how much effort would be involved,
This might be circular dependencies between your LibC and LibB libraries. I
had such problem where it worked on Windows but not on Linux. If this is the
case you can solve it by:
TARGET_LINK_LIBRARIES (A B C B)
Or
TARGET_LINK_LIBRARIES (A B C B C.)
I solved it by defining a library that
I want to set the flag /subsystem to windows for a vc 2005 build, but I
don't want to clear out all the flags and set it. The best way I can think
of to do this is to iterate over the default flags until I get to /subsystem
and remove it and its value, and then add the flag with the value I want.
I have a build tree set up like this:
src/subdirs
builds/linux
builds/win32
install/linux/bin
install/linux/lib
install/win32
where all the source code lives under src, I do out-of-source
builds under builds, and I install built objects into install/linux
and install/win32.
Now I want to
Hi,
I don't know if its the right place to post this question but I wondered it
there is any way to silently suppress makefile warnings ?
E.g.:
CMakeFiles/Makefile2:1999: warning: ignoring old commands for target
CMakeFiles/Makefile2:1601: warning: overriding commands for target
...
It is very
Bill Hoffman wrote:
Daniel Rueckert wrote:
Hi,
I am trying to build some statically linked executables on a linux
box. I have added the -static option to the linker flags and specified
static link libraries but for some reason cmake still adds the option
-Wl,-Bdynamic flag to the linker
I am wondering if there is anyway to suppress the compiler picker dialog
that comes up when you first do configure on a cmakelists. For my project I
want to have an option for what build they want and based on that I would
like to set the compiler through cmake script if possible. Is there anyway
Is it possible to add an option to the GUI that has a drop down list for
choices. I didn't see anyway to do this with the OPTION command.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
On Wednesday 28 November 2007 15:25:33 Jesse Corrington wrote:
Is it possible to add an option to the GUI that has a drop down list for
choices. I didn't see anyway to do this with the OPTION command.
I agree that this would be a very nice feature to have! For instance, it
would be great to
On Nov 28, 2007 5:01 PM, Jesse Corrington [EMAIL PROTECTED] wrote:
I am wondering if there is anyway to suppress the compiler picker dialog
that comes up when you first do configure on a cmakelists. For my project I
want to have an option for what build they want and based on that I would
like
On 2007-11-28 21:57- Daniel Rueckert wrote:
Bill Hoffman wrote:
Daniel Rueckert wrote:
Hi,
I am trying to build some statically linked executables on a linux
box. I have added the -static option to the linker flags and specified
static link libraries but for some reason cmake still adds
Alan W. Irwin wrote:
On 2007-11-28 21:57- Daniel Rueckert wrote:
Bill Hoffman wrote:
Daniel Rueckert wrote:
Hi,
I am trying to build some statically linked executables on a linux
box. I have added the -static option to the linker flags and
specified
static link libraries but for some
Thanks, that works for this specific example. As far as setting other flags,
is my best bet just to do what I was thinking of removing the flag and
re-adding it?
On Nov 28, 2007 2:35 PM, David Cole [EMAIL PROTECTED] wrote:
Instead of trying it the hard way (specifically for /subsystem) why
I am trying to make a platform module to generate symbian build files, so I
was reading the cmake wiki article about cross compiling. It seems to make
pretty good sense, but I have a few questions before I get started.
-After making the toolchain cmake file, is the only way to run cmake with
that
Brandon Van Every wrote:
On Nov 28, 2007 2:47 AM, Pau Garcia i Quiles [EMAIL PROTECTED] wrote:
As DSL based on Lua != Lua, assuming Kitware gets rid of
documentation and bugs in the language might be too optimistic. Look
for example at RHDL (http://rhdl.rubyforge.org/): it's a Ruby-based
DSL
2007/11/28, Stephen Collyer [EMAIL PROTECTED]:
I have a build tree set up like this:
src/subdirs
builds/linux
builds/win32
install/linux/bin
install/linux/lib
install/win32
where all the source code lives under src, I do out-of-source
builds under builds, and I install built objects
2007/11/28, Eric Noulard [EMAIL PROTECTED]:
2007/11/28, Alexander Neundorf [EMAIL PROTECTED]:
On Wednesday 28 November 2007, Mike Jackson wrote:
Has anyone started a QtAssistant version of the CMake Docs? I was
thinking of spending some time trying a few things but I don't want
to
50 matches
Mail list logo
