[CMake] Fwd: How to have generated source compiled multiple ways?

2013-08-12 Thread Eric Noulard
2013/8/12 Paul Smith :
> On Mon, 2013-08-12 at 22:35 +0200, Eric Noulard wrote:
>> 2013/8/12 Paul Smith :
>> >
>> > So I have tried using add_custom_command() with OUTPUT, but the
>> > documentation says:
>> >
>> > "Do not list the output in more than one independent target that may build
>> > in parallel or the two instances of the rule may conflict (instead use
>> > add_custom_target to drive the command and make the other targets depend on
>> > that one)."
>> >
>> > Sure enough, it seems that if I have my different libraries depend on these
>> > outputs I get problems during parallel builds.  So then I tried to use
>> > add_custom_target(), but that says:
>> >
>> > "The target has no output file and is ALWAYS CONSIDERED OUT OF DATE"
>> >
>> > and, sure enough, if I do it this way my source files (and everything that
>> > depends on them) rebuild every time I run the build, even if nothing has
>> > changed.  This is a big bummer.
>>
>> I did never tried befoire but think you should "simply" keep your
>> current add_custom_command and create a new target with
>> add_custom_target whose only purpose is to "serialize" the dependency
>> for the 2 (or more) independent libraries which use the output of your
>> custom command concurrently.
>
>> add_custom_target(SerializeTarget
>>   DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/generated.c)
>>
>> add_library(MyLib1 ${CMAKE_CURRENT_BINARY_DIR}/generated.c lib1.c)
>> set_target_properties(MyLib1 PROPERTIES COMPILE_FLAGS -DDEFGEN=3)
>> add_dependencies(MyLib1 SerializeTarget)
>>
>> add_library(MyLib2 ${CMAKE_CURRENT_BINARY_DIR}/generated.c lib2.c)
>> set_target_properties(MyLib2 PROPERTIES COMPILE_FLAGS -DDEFGEN=4)
>> add_dependencies(MyLib2 SerializeTarget)
>
> OK, maybe I'm misunderstanding but if the SerializeTarget is considered
> "always out of date" because it was defined with add_custom_target()
> then won't that cause the two libraries to always rebuild, since
> something they depend on is always out of date?  Maybe I'm thinking of
> it too much like make.

This is puzzling but as far as I understand it, since SerializeTarget
has no output
it cannot trigger the rebuilt of a target (nioether Lib1 nor Lib2),
however whenever
you need (or ask) to build Lib1 or Lib2 then SerializeTarget has to be executed
and consequently the add_custom_command will be if the "generated.c" file is
out of date.

i.e. if you build Lib1 or Lib2 then SerializeTarget will be built.
Building Lib1 target does not mean recompilation will occur
because the "file dependency" is automatically handled by
cmake using the source files arguments of the add_library call.

so you may have:
$ make
[ 14%] Built target SerializeTarget
[ 57%] Built target MyLib1
[100%] Built target MyLib2

every expected target is built (because of the target dependencies) but
no compilation occurs because none is necessary.

but
$ rm generated.c
$ make
[ 14%] Generating generated.c
[ 14%] Built target SerializeTarget
Scanning dependencies of target MyLib1
[ 28%] Building C object CMakeFiles/MyLib1.dir/generated.c.o
Linking C static library libMyLib1.a
[ 57%] Built target MyLib1
Scanning dependencies of target MyLib2
[ 71%] Building C object CMakeFiles/MyLib2.dir/generated.c.o
Linking C static library libMyLib2.a
[100%] Built target MyLib2

works as expected, and
$ touch ../lib1.c
erk@ct-wdtim102h:b$ make
[ 14%] Built target SerializeTarget
Scanning dependencies of target MyLib1
[ 28%] Building C object CMakeFiles/MyLib1.dir/lib1.c.o
Linking C static library libMyLib1.a
[ 57%] Built target MyLib1
[100%] Built target MyLib2

as well.

> I'll look at the stuff you've sent and try to adjust it for my
> situation.

It should work.

-- 
Erk
L'élection n'est pas la démocratie -- http://www.le-message.org
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake


Re: [CMake] How to have generated source compiled multiple ways?

2013-08-12 Thread Paul Smith
On Mon, 2013-08-12 at 22:35 +0200, Eric Noulard wrote:
> 2013/8/12 Paul Smith :
> >
> > So I have tried using add_custom_command() with OUTPUT, but the
> > documentation says:
> >
> > "Do not list the output in more than one independent target that may build
> > in parallel or the two instances of the rule may conflict (instead use
> > add_custom_target to drive the command and make the other targets depend on
> > that one)."
> >
> > Sure enough, it seems that if I have my different libraries depend on these
> > outputs I get problems during parallel builds.  So then I tried to use
> > add_custom_target(), but that says:
> >
> > "The target has no output file and is ALWAYS CONSIDERED OUT OF DATE"
> >
> > and, sure enough, if I do it this way my source files (and everything that
> > depends on them) rebuild every time I run the build, even if nothing has
> > changed.  This is a big bummer.
> 
> I did never tried befoire but think you should "simply" keep your
> current add_custom_command and create a new target with
> add_custom_target whose only purpose is to "serialize" the dependency
> for the 2 (or more) independent libraries which use the output of your
> custom command concurrently.

> add_custom_target(SerializeTarget
>   DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/generated.c)
> 
> add_library(MyLib1 ${CMAKE_CURRENT_BINARY_DIR}/generated.c lib1.c)
> set_target_properties(MyLib1 PROPERTIES COMPILE_FLAGS -DDEFGEN=3)
> add_dependencies(MyLib1 SerializeTarget)
> 
> add_library(MyLib2 ${CMAKE_CURRENT_BINARY_DIR}/generated.c lib2.c)
> set_target_properties(MyLib2 PROPERTIES COMPILE_FLAGS -DDEFGEN=4)
> add_dependencies(MyLib2 SerializeTarget)

OK, maybe I'm misunderstanding but if the SerializeTarget is considered
"always out of date" because it was defined with add_custom_target()
then won't that cause the two libraries to always rebuild, since
something they depend on is always out of date?  Maybe I'm thinking of
it too much like make.

I'll look at the stuff you've sent and try to adjust it for my
situation.

Thanks!

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake


Re: [CMake] How to have generated source compiled multiple ways?

2013-08-12 Thread Eric Noulard
2013/8/12 Paul Smith :
> Hi all.
>
> I've got a situation where I'm creating generated source files (from
> bison/flex, actually, but I'm writing my own rules for it since I need
> specialized support for C++ output, etc.)
>
> However I need to compile the generated output into two different libraries,
> building two different ways (with different #defines/compiler flags).
>
> So I have tried using add_custom_command() with OUTPUT, but the
> documentation says:
>
> "Do not list the output in more than one independent target that may build
> in parallel or the two instances of the rule may conflict (instead use
> add_custom_target to drive the command and make the other targets depend on
> that one)."
>
>
> Sure enough, it seems that if I have my different libraries depend on these
> outputs I get problems during parallel builds.  So then I tried to use
> add_custom_target(), but that says:
>
> "The target has no output file and is ALWAYS CONSIDERED OUT OF DATE"
>
>
> and, sure enough, if I do it this way my source files (and everything that
> depends on them) rebuild every time I run the build, even if nothing has
> changed.  This is a big bummer.

I did never tried befoire but think you should "simply" keep your
current add_custom_command
and create a new target with add_custom_target whose only purpose is
to "serialize"
the dependency for the 2 (or more) independent libraries which use the
output of your custom command
concurrently.

Something like:
cmake_minimum_required(VERSION 2.8.10)
project(ParallelAddCustomCommand C)

add_custom_command(OUTPUT  ${CMAKE_CURRENT_BINARY_DIR}/generated.c
  COMMAND ${CMAKE_COMMAND} -E copy
${CMAKE_CURRENT_SOURCE_DIR}/template.c
${CMAKE_CURRENT_BINARY_DIR}/generated.c)

add_custom_target(SerializeTarget
  DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/generated.c)

add_library(MyLib1 ${CMAKE_CURRENT_BINARY_DIR}/generated.c lib1.c)
set_target_properties(MyLib1 PROPERTIES COMPILE_FLAGS -DDEFGEN=3)
add_dependencies(MyLib1 SerializeTarget)

add_library(MyLib2 ${CMAKE_CURRENT_BINARY_DIR}/generated.c lib2.c)
set_target_properties(MyLib2 PROPERTIES COMPILE_FLAGS -DDEFGEN=4)
add_dependencies(MyLib2 SerializeTarget)

> How can I have generated source files compiled different ways into different
> libraries, but not have them (and anything that depends on them) rebuilt
> every time?
>
>
> The only way I've thought of so far is to have two different
> add_custom_command() options with the same input but different output (in
> different directories maybe), one for each target.  This means I need to
> generate the files twice even though the output source files will have
> identical content.  But as long as I don't have to REBUILD them every time
> maybe that's not so bad.  I haven't tried this yet though.  Are there other
> options?

I tried to craft some working example which is attached to this mail.

-- 
Erk
L'élection n'est pas la démocratie -- http://www.le-message.org


ParallelAddCustomCommand.tgz
Description: GNU Zip compressed data
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] How to have generated source compiled multiple ways?

2013-08-12 Thread Paul Smith
Hi all.

I've got a situation where I'm creating generated source files (from
bison/flex, actually, but I'm writing my own rules for it since I need
specialized support for C++ output, etc.)

However I need to compile the generated output into two different
libraries, building two different ways (with different #defines/compiler
flags).

So I have tried using add_custom_command() with OUTPUT, but the
documentation says: 


"Do not list the output in more than one independent target that
may build in parallel or the two instances of the rule may
conflict (instead use add_custom_target to drive the command and
make the other targets depend on that one)."


Sure enough, it seems that if I have my different libraries depend on
these outputs I get problems during parallel builds.  So then I tried to
use add_custom_target(), but that says:


"The target has no output file and is ALWAYS CONSIDERED OUT OF
DATE"


and, sure enough, if I do it this way my source files (and everything
that depends on them) rebuild every time I run the build, even if
nothing has changed.  This is a big bummer.


How can I have generated source files compiled different ways into
different libraries, but not have them (and anything that depends on
them) rebuilt every time?


The only way I've thought of so far is to have two different
add_custom_command() options with the same input but different output
(in different directories maybe), one for each target.  This means I
need to generate the files twice even though the output source files
will have identical content.  But as long as I don't have to REBUILD
them every time maybe that's not so bad.  I haven't tried this yet
though.  Are there other options?
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Difference between CMake generated Xcode project and manually created 'bsd c library' project

2013-08-12 Thread Michael Norman
I have a project where the output is a static library. The directory
structure is as follows:

myproj
   |  CMakeLists.txt
   |- cmake_macros
   |find_include_dirs.cmake
   |- libs
   |--- Mac
   |- lib
   | libcrypto.a
   | ...
   |--- win
   | ...
   |
   |- src
   |--- component1
   |   CMakeLists.txt
   |   some_file.c
   |   ...
   |- include
   |   CMakeLists.txt
   |   some_file.h
   |   ...
   |--- component2
   | ...

Each component's cmake file describes the sources and headers for that
component:

project(component1)
set(component1_SOURCES
${CMAKE_CURRENT_SOURCE_DIR}/some_file.c
${CMAKE_CURRENT_SOURCE_DIR}/some_other_file.c
)
set(component1_HEADERS
${CMAKE_CURRENT_SOURCE_DIR}/include/some_file.h
${CMAKE_CURRENT_SOURCE_DIR}/include/some_other_file.h
)
add_library(component1 OBJECT ${component1_SOURCES} ${component1_HEADERS})

The top-level cmake file includes each sub-component and builds the
required library:

cmake_minimum_required (VERSION 2.8)
include(cmake_macros/find_include_dirs.cmake)

project (myProject C)

# find all include directories
find_include_dirs(INCLUDE_DIRS)
include_directories(${INCLUDE_DIRS})

# add subdirectories
add_subdirectory(src/component1)
add_subdirectory(src/component2)
...

# platform-specific compiler flags
if (APPLE)
set(ENV{CC} clang)
set(CMAKE_C_FLAGS "-std=gnu99" CACHE STRING "" FORCE)
set(CMAKE_SHARED_LINKER_FLAGS "-Wl,--export-all-symbols")
   ...
endif (APPLE)

add_library(myLib STATIC
$
$
...
)

When run without a generator, the command-line compilation works, producing
myLib.a; however, when I generate an Xcode project, I get multiple .a
files, one-per component and no target that links everything together into
a single library.

Any help would be greatly appreciated,
---
Mike Norman
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CPack using Inno Setup compilation scripts ?

2013-08-12 Thread Nicolas Desprès
Hi,

I am afraid you will have to write a new generator for cpack. It is not as
hard as it sound but you will have to write C++ code. That would be great
if cpack could support inno setup since it is much easier to hack inno
setup script than NSIS script.

Cheers,
-Nico



On Monday, August 12, 2013, Nitentore Tentyris wrote:

> Hi folks,
>
> (hope this post does not double up with an existing one ; I tried to check
> past posts in the archives but did not find any)
>
> I have this existing project on Windows (only) that require some automatic
> packaging - the current procedure is a painful doc to read and follow with
> multiple steps --> prone to error.
>
> From the CPack documentation, I see that it could really help me on this
> task.
>
> Among various things, one of the final step of the current procedure is to
> execute an InnoSetup compilation script (the step that generates a package
> - not the step consisting of executing an install). This inno setup script
> is not trivial and contains quite a lot of work, so I really do not want to
> 'redo' this part, I just want to use it.
>
> I've got some little experience with cmake, ctest and cdash. I have got
> lib and exe svn-updated, built, tested and reported to cdash every night
> and then, but I did not do anything with cpack (yet)... thought it was a
> good way to start :).
> Some sub-part / sub-tree of the project are already using cmake.
>
> My question:
> I have read that cpack "works" with NSIS... but how does it stand with
> InnoSetup ??? Could not find in the docs and in my google searches any
> positive insight on how to make my InnoSetup compilation script to work
> with CPack.
> Maybe I missed an article or a paragraph in the docs. Any pointers ?
>
> Otherwise my fallback position will be to script everything with some
> higher level batch file (argh!).
>
> Thanks in advance for your advices.
>
> Cheers;
> Nit.
>
>

-- 
Nicolas Desprès
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CPack using Inno Setup compilation scripts ?

2013-08-12 Thread Nitentore Tentyris
Hi folks,

(hope this post does not double up with an existing one ; I tried to check
past posts in the archives but did not find any)

I have this existing project on Windows (only) that require some automatic
packaging - the current procedure is a painful doc to read and follow with
multiple steps --> prone to error.

>From the CPack documentation, I see that it could really help me on this
task.

Among various things, one of the final step of the current procedure is to
execute an InnoSetup compilation script (the step that generates a package
- not the step consisting of executing an install). This inno setup script
is not trivial and contains quite a lot of work, so I really do not want to
'redo' this part, I just want to use it.

I've got some little experience with cmake, ctest and cdash. I have got lib
and exe svn-updated, built, tested and reported to cdash every night and
then, but I did not do anything with cpack (yet)... thought it was a good
way to start :).
Some sub-part / sub-tree of the project are already using cmake.

My question:
I have read that cpack "works" with NSIS... but how does it stand with
InnoSetup ??? Could not find in the docs and in my google searches any
positive insight on how to make my InnoSetup compilation script to work
with CPack.
Maybe I missed an article or a paragraph in the docs. Any pointers ?

Otherwise my fallback position will be to script everything with some
higher level batch file (argh!).

Thanks in advance for your advices.

Cheers;
Nit.
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake