hello list,
I am running Xcode (5 & 6) and using CMake to generate the Xcode project
files. We have a lot of targets for our project and we were looking into ways
of refactoring the Cmake codes in order to reduce the number of targets. For
example we have a lot of plugins that we compile
I'm developing a software package which consists of a GUI application
and a command line program. Both programs share common libraries, and
essentially they only differ in which UI components each program uses.
I would like to use CMake to handle the build project of this package,
but as I
Hi,
On Sun, Oct 28, 2012 at 10:09 PM, Rui Maciel rui.mac...@gmail.com wrote:
I'm developing a software package which consists of a GUI application and a
command line program. Both programs share common libraries, and essentially
they only differ in which UI components each program uses.
I
PCJohn wrote:
Thanks. VERBATIM was the problem. After, removing it, the code works
perfectly. Thanks!
Anyway, I am a little bit puzzled with documentation, as it states:
In the future VERBATIM may be enabled by default. The only reason
it is an option is to preserve compatibility with
Your initial attempt looks reasonable... Did you try it without the
VERBATIM argument to the ADD_CUSTOM_COMMAND?
This sort of copy command should work if invoked from Visual Studio, even
with the $(OutDir) reference...
HTH,
David
On Sun, Jun 1, 2008 at 10:29 AM, Pečiva Jan [EMAIL PROTECTED]
Thanks. VERBATIM was the problem. After, removing it, the code works
perfectly. Thanks!
Anyway, I am a little bit puzzled with documentation, as it states:
In the future VERBATIM may be enabled by default. The only reason
it is an option is to preserve compatibility with older CMake code.
I
Dears cmakers,
I am about to finish my dual gui/console behaviour for InventorTools
utilities. Compilation of whole set of executables is perfectly
handled by cmake, but final installation procedure does not work.
Can cmake handle this situation?:
1. cmake builds all the executables of
On 2008-06-01 16:29+0200 Pe�iva Jan wrote:
install (TARGETS autoconsole
RUNTIME
DESTINATION bin
RENAME ivview.exe)
It copies the file, but RENAME does not work (It probably works only for
PROGRAMS and FILES signatures). I was planning to use this command about ten
[...] if you instead set the OUTPUT_NAME property of the target
using set_target_properties, I believe you will get the result
you want.
I guess, that would be the option if I would need just one
executable. But I need ten executables - each one of different name.
Simlinks, etc. are not an
On 2008-06-01 23:17+0200 PCJohn wrote:
[...] if you instead set the OUTPUT_NAME property of the target
using set_target_properties, I believe you will get the result
you want.
I guess, that would be the option if I would need just one
executable. But I need ten executables - each one of
Hi all,
is there anything new regarding this issue :
http://www.cmake.org/pipermail/cmake/2005-September/007271.html
This is a real problem, and the static library hack doesn't work well
if you have many executables that don't all use all the object files :
changing one single file will cause a
On Dec 19, 2007 7:34 AM, Joël Schaerer [EMAIL PROTECTED] wrote:
Hi all,
is there anything new regarding this issue :
http://www.cmake.org/pipermail/cmake/2005-September/007271.html
I have read this FAQ entry, but it doesn't seem to adress my issue at all...
joel
Quoting Brandon Van Every [EMAIL PROTECTED]:
On Dec 19, 2007 7:34 AM, Joël Schaerer [EMAIL PROTECTED] wrote:
Hi all,
is there anything new regarding this issue :
On Dec 19, 2007 10:47 AM, Joël Schaerer [EMAIL PROTECTED] wrote:
I have read this FAQ entry, but it doesn't seem to adress my issue at all...
Did you read http://www.cmake.org/Bug/view.php?id=5155 ?
Cheers,
Brandon Van Every
___
CMake mailing list
On Dec 19, 2007 11:08 AM, Joel Schaerer [EMAIL PROTECTED] wrote:
Thanks a lot. This is a real issue since compiling everything two or ten times
just for the sake of it is *not* efficient. We are currently considering
switching back to makefiles and a custom VS project because of this.
I'd be
Brandon Van Every wrote:
On Dec 19, 2007 11:08 AM, Joel Schaerer [EMAIL PROTECTED] wrote:
Thanks a lot. This is a real issue since compiling everything two or ten times
just for the sake of it is *not* efficient. We are currently considering
switching back to makefiles and a custom VS project
Maybe I am missing something, but why not create a static library and
share it with the executables? Why try to reuse object files? CMake
makes it very easy to create static libraries and link them to executables.
-Bill
Because then you have to relink all executables each time you change
I work on a similarly large project and have found that building shared
libraries for development is much faster (in terms of compile/link time)
when making small changes (working in Visual Studio). Nightly or test builds
can use static libraries to produce single executables.
Provided you have
On Dec 19, 2007 11:28 AM, Bill Hoffman [EMAIL PROTECTED] wrote:
Maybe I am missing something, but why not create a static library and
share it with the executables?
The end product may not be an executable, it may be a static library.
A static library cannot include another static library. I
On Wednesday 19 December 2007, Joel Schaerer wrote:
Maybe I am missing something, but why not create a static library and
share it with the executables? Why try to reuse object files? CMake
makes it very easy to create static libraries and link them to
executables.
-Bill
Because
Quoting Alexander Neundorf [EMAIL PROTECTED]:
On Wednesday 19 December 2007, Joel Schaerer wrote:
Maybe I am missing something, but why not create a static library and
share it with the executables? Why try to reuse object files? CMake
makes it very easy to create static libraries and
On Wednesday 19 December 2007, you wrote:
...
Yeah, you could even create one static library per executable...
Awesome! What was the problem with putting all the object files in the
same directory, again? Shouldn't that be an option, at least? It would
be SO much easier than all the dirty
Quoting Alexander Neundorf [EMAIL PROTECTED]:
On Wednesday 19 December 2007, you wrote:
...
Yeah, you could even create one static library per executable...
Awesome! What was the problem with putting all the object files in the
same directory, again? Shouldn't that be an option, at least? It
One other very good reason, too:
Same target may have two source files of the exact same name, but they exist
in different directories (Abc/Object.cxx and Def/Object.cxx). In that case,
the object files will be further hidden in subdirectories to avoid two files
in the object files directory from
Quoting David Cole [EMAIL PROTECTED]:
One other very good reason, too:
Same target may have two source files of the exact same name, but they exist
in different directories (Abc/Object.cxx and Def/Object.cxx). In that case,
the object files will be further hidden in subdirectories to avoid two
Compilation time is only multiplied if you are specifying the same source
file in multiple targets. If you are seeing a 2x difference, then you must
have *all* of your source files listed twice. Shouldn't this only be for a
few of your source files at most?
I would argue that it's better to be
On Dec 19, 2007 3:41 PM, David Cole [EMAIL PROTECTED] wrote:
One other very good reason, too:
Same target may have two source files of the exact same name, but they exist
in different directories (Abc/Object.cxx and Def/Object.cxx). In that case,
the object files will be further hidden in
On 12/19/07, Brandon Van Every [EMAIL PROTECTED] wrote:
...an easy feature to
implement...
So easy to implement that the attached patch was 0 bytes...?
:-)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
On Dec 19, 2007 3:52 PM, David Cole [EMAIL PROTECTED] wrote:
Compilation time is only multiplied if you are specifying the same source
file in multiple targets. If you are seeing a 2x difference, then you must
have *all* of your source files listed twice. Shouldn't this only be for a
few of
On Dec 19, 2007 4:24 PM, David Cole [EMAIL PROTECTED] wrote:
On 12/19/07, Brandon Van Every [EMAIL PROTECTED] wrote:
...an easy feature to
implement...
So easy to implement that the attached patch was 0 bytes...?
Bill's comments at http://www.cmake.org/Bug/view.php?id=5155 about
the
Where are these 10 lines? Can you post them here or point to the chicken
.cmake source file that contains them?
On 12/19/07, Brandon Van Every [EMAIL PROTECTED] wrote:
On Dec 19, 2007 4:24 PM, David Cole [EMAIL PROTECTED] wrote:
On 12/19/07, Brandon Van Every [EMAIL PROTECTED] wrote:
On Dec 19, 2007 7:32 PM, David Cole [EMAIL PROTECTED] wrote:
Where are these 10 lines?
In the bug tracker, conspiciously above Bill's comments. They've been
there for 6 months.
http://www.cmake.org/Bug/view.php?id=5155
On 12/19/07, Brandon Van Every [EMAIL PROTECTED] wrote:
On Dec 19,
32 matches
Mail list logo
