[CMake] Boost and multiplatform configurations

2010-12-02 Thread Dmytro Ovdiienko
Hello all,

I have a library that depends on boost. One user of this library compiles
only x32 version. Second user compiles x64. Third user compiles both x32 and
x64.

First user has only x32 version of the boost in the BOOST_LIBRARYDIR.
Second user only x64 version in the BOOST_LIBRARYDIR.
Third user has both x32 in the BOOST_LIBRARYDIR/x32 and x64 version in the
BOOST_LIBRARYDIR/x64.

The question is how to configure boost to search BOOST_LIBRARYDIR/
folder first then BOOST_LIBRARYDIR?
BOOST_LIBRARYDIR does not support values list. Previous CMake 2.6 version
used to support list of the values.

Thanks.


-- 
Dmytro Ovdiienko
___
Powered by www.kitware.com

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

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

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

Re: [CMake] FindBoost: find both win32 and x64 static libs

2010-12-02 Thread Dmytro Ovdiienko
Hicham,

You can force boost to add compiler name to the library file name. Add
"--layout=versioned" to the bjam command line.

On 1 December 2010 00:37, Hicham Mouline  wrote:

>  As boost libraries naming convention doesn't include in the lib names
> whether they are built by msvc9 win32 or x64, I am forced on a winxp 64 box
> where I hold both versions to have a different lib directory under
> boost_root.
>
> I set BOOST_ROOT then call FIND_PACKAGE(Boost 1.44 COMPONENTS ...).
>
> Am I supposed to detect which of vc9 32bit or 64bit am  I generating for
> and then set BOOST_LIBRARYDIR depending on that before calling FIND_PACKAGE?
>
> How do I detect bitness?
>
> ___
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>



-- 
Dmytro Ovdiienko
___
Powered by www.kitware.com

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

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

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

Re: [CMake] FindBoost: find both win32 and x64 static libs

2010-12-07 Thread Dmytro Ovdiienko
Hicham,

Sorry for confusing. I supposed you asked about how to handle different
versions of the Boost (1.42, 1.44 etc) on the same build server.



On 6 December 2010 00:16, Hicham Mouline  wrote:

> > -Original Message-
> > From: philiplow...@gmail.com [mailto:philiplow...@gmail.com] On Behalf
> > Of Philip Lowman
> > Sent: 05 December 2010 04:54
> > To: Hicham Mouline
> > Cc: Philip Lowman; CMake mailing list
> > Subject: Re: [CMake] FindBoost: find both win32 and x64 static libs
> >
> > On Saturday, December 4, 2010, Hicham Mouline 
> > wrote:
> > >
> > > I was wrong. Dmytro pointed out that bjam allows building boost
> > > libraries with the compiler and bitness in the boost library name --
> > layout=versioned.
> > >
> > > Therefore, I could have both 32 and 64bit versions in the same
> > > directory.
> > >
> > > I wonder then if FindBoost is able to detect automatically the
> > > right ones based on the name of the libs.
> >
> > I could probably add this feature, I'm pretty sure there isn't support
> > for it now.  Could you create a feature request on the CMake bug
> > tracker and include what the filenames look like when generated by
> > visual studio?
> >
> > If you want to try to patch FindBoost yourself, please make sure
> > you're playing with the version from 2.8.3.
> >
> > http://www.cmake.org/Bug
> > Philip Lowman
>
> I've built both win32 and x64 versions of boost thread library with the
> following 2 lines:
>
> 1. 32bit cl.exe from msvc9 directory in the %PATH%
> bjam --with-thread --layout=versioned toolset=msvc address-model=64
> variant=release link=static threading=multi runtime-link=shared
>
> 2. 64bit cl.exe from msvc9 directory in the %PATH%
> bjam --with-thread --layout=versioned toolset=msvc address-model=64
> variant=release link=static threading=multi runtime-link=shared
>
> however, the resulting .lib files have identical names however:
> libboost_thread-vc90-mt-1_44.lib
> libboost_thread-vc90-mt.lib
>
> Dmytro, there is no distinction between 32bit and 64bit. The 64bit lib size
> is approximately double the 32bit lib.
>
> boost-build, how to change this to include the bitness in the boost lib
> name?
> If it's impossible, Philip, perhaps FindBoost could be changed to allow for
> different directories under BOOST_ROOT for the lib directories, something
> like lib\win32 and lib\x64 or whatever names can be agreed on.
>
> rds,
>
>


-- 
Dmytro Ovdiienko
e-mail: dmitriy.ovdie...@gmail.com
skype: dmitriy.ovdie...@gmail.com
mobile: +38050-1909731
___
Powered by www.kitware.com

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

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

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

Re: [CMake] FindBoost: find both win32 and x64 static libs

2010-12-15 Thread Dmytro Ovdiienko
Philip,

I like it. That is exactly I tried to achieve with BOOST_LIBRARYDIR. However
BOOST_LIBRARYDIR does not support list values in the CMake 2.8.2.

On 7 December 2010 15:16, Philip Lowman  wrote:

> On Sunday, December 5, 2010, Hicham Mouline  wrote:
>
>  > I've built both win32 and x64 versions of boost thread library with the
> > following 2 lines:
> >
> > 1. 32bit cl.exe from msvc9 directory in the %PATH%
> > bjam --with-thread --layout=versioned toolset=msvc address-model=64
> > variant=release link=static threading=multi runtime-link=shared
> >
> > 2. 64bit cl.exe from msvc9 directory in the %PATH%
> > bjam --with-thread --layout=versioned toolset=msvc address-model=64
> > variant=release link=static threading=multi runtime-link=shared
> >
> > however, the resulting .lib files have identical names however:
> > libboost_thread-vc90-mt-1_44.lib
> > libboost_thread-vc90-mt.lib
> >
> > Dmytro, there is no distinction between 32bit and 64bit. The 64bit lib
> size
> > is approximately double the 32bit lib.
> >
> > boost-build, how to change this to include the bitness in the boost lib
> > name?
> > If it's impossible, Philip, perhaps FindBoost could be changed to allow
> for
> > different directories under BOOST_ROOT for the lib directories, something
> > like lib\win32 and lib\x64 or whatever names can be agreed on.
>
> If the user is compiling 32-bit code I could make FindBoost search "lib32"
> before "lib" and for 64-bit code I can make it search "lib64" before "lib".
>  If the user had an empty lib64 directory for some reason, it would still
> find the boost libraries in "lib".
>
> Would this work for you?
>
> The BOOST_LIBRARYDIR variable is the only other workaround I can think to
> this issue.
>



-- 
Dmytro Ovdiienko
___
Powered by www.kitware.com

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

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

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

Re: [CMake] Coloured output for cmake on windows

2010-01-10 Thread Dmytro Ovdiienko
Vikas,

Error and Warning messages are colored.

2010/1/9 Chauhan, Vikas 

>  Hi,
>
> I guess there is no end to wishes & this is another example of it.
>
> Is it possible to get a coloured output on windows using a build command
> like: cmake –-build . ?
>
> Currently is it because dos cmd window doesn’t support it or there is 
> someother reason?
>
> Thanks,
>
> Vikas
>
> ___
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>
___
Powered by www.kitware.com

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

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

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

Re: [CMake] Running tests as part of a build

2010-01-10 Thread Dmytro Ovdiienko
Gavin,

Good practice is to run as much tests as possible and do not stop on first
failed test.

2010/1/8 Gavin Heavyside 

> Have you looked at add_custom_command(TARGET ...) or
>> add_custom_target(...)?
>>  Those are how you run can run commands as part of the build, but after
>> some
>> other targets are compiled.
>>
>> Clint
>>
>
> That works great, thanks for the tip!
>
> I build my code, and then my test programs using add_executable.  Then I
> can do e.g.:
>
> add_custom_command(TARGET test_harness POST_BUILD COMMAND test_harness)
>
> and test_harness runs after building, with proper dependencies, and a
> failing test causes a failing build.  Perfect.  Anything I don't want to run
> by default I can leave to add_test on its own.
>
> Thanks very much,
>
> Gavin
>
> ___
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>
___
Powered by www.kitware.com

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

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

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

Re: [CMake] Inheriting include directories from dependencies

2009-01-17 Thread Dmytro Ovdiienko
2009/1/16 Robert Dailey 

> Hi,
>
> Currently I'm specifying include directories on a per-project basis.
> Suppose I have projects A, B, and C. Project C would depend on A and B by
> specifying A and B in a call to target_link_libraries(). Both projects A and
> B have include directories that I set via a call to include_directories()
> and the directories are not the same. The include directories I use are
> those given to me by various Find modules (find_package()).
>
> The thing is that include files in A and B (Which I reference in the source
> code for project C) include header files in external dependencies of A and
> B. This means that project C will not compile unless it has the include
> directories available for the dependencies of both A and B. Is there a built
> in feature that facilitates inheriting include directories from A and B and
> placing them into C implicitly? If not, is there some work-around for this?
>
> Thanks.
>
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>


Hello Robert,

I have a big project with wide structure and I interested in include
directory inheriting too. I believe if project A depends on B in 90% cases
it uses include directories from B and B::include_directories.

Suppose we have ask developers about this feature.

Regards,
Dmytro Ovdiienko
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Recompile with different flags

2009-01-19 Thread Dmytro Ovdiienko
Adam,

How about two configurations for your library: cfg_1, cfg_2.
cfg_1 - is configuration without flag.
cfg_2 - is configuration with flag.

2009/1/19 Adam Weiss >

> I couldn't find an answer to this, so I thought I should ask.
>
> I have a set of source files that are compiled and built into a library.
> Works great.
> Now I want to recompile those same files with a compiler flag added into
> another library.  Don't ask, this is how it has to be.
>
> I tried doing add_library, then set_source_files_properties, then
> add_library but then the flag is set for both.
>
> I would like to keep it all inside of one CMakeLists.txt file, but I might
> be able to work it out another way.
>
>
> Thanks for any help,
> Adam
> ___
> 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] Build-order in Visual Studio

2009-01-26 Thread Dmytro Ovdiienko
Micha,

Use 
*target_link_libraries
* and 
*add_dependencies
* to fix project build order.

2009/1/26 Micha Renner 

> Hello,
>
> is it possible to influence the build-order of MSVC from
> CMakeLists.txt-files?
>
> The top-level CMakeLists.txt looks like this:
>
> ADD_SUBDIRECTORY(lib1)
> ADD_SUBDIRECTORY(lib2)
> ADD_SUBDIRECTORY(lib3)
> ADD_SUBDIRECTORY(lib4)
> ADD_SUBDIRECTORY(prog)
>
> prog depends on the libs. lib3 depends on lib1 and lib4 depends on lib2.
> After a cMake-run the build-order in Visual Studio is "pure" random,
> even the main-program is sometimes ZERO_CHECK.
>
> Michael
>
>
> ___
> 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] debug, optimized, and custom

2009-03-02 Thread Dmytro Ovdiienko
All,

if I have several configurations (e.g. /MT, /MTd, /MD, /MDd), how can I pass
additional libraries to the target_link_libraries? I have two optimized
libaries. One for /MT and one for /MD.

Thanks,
Dima

2009/2/25 

> On Wed, Feb 25, 2009 at 1:38 AM, Hendrik Sattler 
> wrote:
> debug and optimized keywords are followed by _one_ library. The help entry
> defines this correctly.
>
> Thanks and sorry I missed that in the help. cmake really is amazing, but I
> also find it massive. The "Mastering Cmake" book is excellent, but if people
> write an even longer text with lots of tutorial examples I promise to buy
> it.
>
> I have now changed things around to do the following:
> #Set in my find module.
> set(ETK_LIBS debug scl-d
> optimized scl
> debug libIpopt-mt-d
> optimized libIpopt-mt) #in reality, there are about 20 libs
>
> #set in my cmakelists.txt for my project.
> add_executable(hello2 ${hello2_SRCS})
> target_link_libraries(hello2 ${ETK_LIBS })
>
> Is this the best way to setup long lists of libraries to link in?
>
> And is there any way for me to have separate lists that work for my custom
> build type that works in visual studio? I want an MPI and heavily optimized
> build type that people can choose.
> ___
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>
___
Powered by www.kitware.com

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

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

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

Re: [CMake] debug, optimized, and custom

2009-03-02 Thread Dmytro Ovdiienko
Hi,

Suppose, IMPORTED libraries should help. Following is text from CMake
manual:

Higher granularity may be achieved for per-configuration rules by creating
and linking to IMPORTED library targets. See the IMPORTED mode of the
add_library command for more information.

See also http://www.cmake.org/Wiki/CMake_2.6_Notes#Importing_Targets

2009/3/2 

> For nmake, I think you do it conditional based on the BUILD_TYPE variable.
> But this won't work for visual studio, because this variable isn't
> available. Noone answered my original question about this... Can you repost
> to the mailing list the question?
>
> The only thing I can think of is to have an option(USE_MD) or something,
> where you can generate the libraries differently depending on this option in
> the cache. But I really don't know cmake all that well.
>
>
> On Mar 2, 2009 1:28pm, Dmytro Ovdiienko 
> wrote:
> > All,
> >
> > if I have several configurations (e.g. /MT, /MTd, /MD,
> > /MDd), how can I pass additional libraries to the
> > target_link_libraries? I have two optimized libaries. One for /MT and
> > one for /MD.
> >
> > Thanks,
> > Dima
> >
> > 2009/2/25 jessepe...@gmail.com>
> >
> > On Wed, Feb 25, 2009 at 1:38 AM, Hendrik Sattler p...@hendrik-sattler.de>
> wrote:
> > debug and optimized keywords are followed by _one_ library. The help
> entry
> >
> > defines this correctly.
> >
> >
> > Thanks and sorry I missed that in the help. cmake really is amazing, but
> I also find it massive. The "Mastering Cmake" book is excellent, but if
> people write an even longer text with lots of tutorial examples I promise to
> buy it.
> >
> >
> > I have now changed things around to do the following:
> > #Set in my find module.
> > set(ETK_LIBS debug scl-d
> > optimized scl
> > debug libIpopt-mt-d
> > optimized libIpopt-mt) #in reality, there are about 20 libs
> >
> >
> > #set in my cmakelists.txt for my project.
> > add_executable(hello2 ${hello2_SRCS})
> > target_link_libraries(hello2 ${ETK_LIBS })
> >
> > Is this the best way to setup long lists of libraries to link in?
> >
> > And is there any way for me to have separate lists that work for my
> custom build type that works in visual studio? I want an MPI and heavily
> optimized build type that people can choose.
> >
> > ___
> >
> > Powered by www.kitware.com
> >
> >
> >
> > Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> >
> >
> >
> > Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
> >
> >
> >
> > Follow this link to subscribe/unsubscribe:
> >
> > http://www.cmake.org/mailman/listinfo/cmake
> >
> >
> >
>
___
Powered by www.kitware.com

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

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

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

[CMake] exe/a/so sufixes depend on configuration

2009-03-04 Thread Dmytro Ovdiienko
Hello All,

I use CMake to build my project's sources on windows and linux using static
and dynamic runtimes.

I would like to add information about build configuration to the output file
name as suffix.

For instance:
  - libsome_lib_*linux_x32*.a - static library "some_lib" for linux 32bit
  - some_lib_*windows_x64_md*.lib - static library "some_lib" for windows
64bit with dynamic release runtime
  - some_lib_*windows_x62_mtd*.lib - static library "some_lib" for windows
32bit with static debug runtime

For windows I generate projects with debug and release configurations.

Right now I play with
  - CMAKE_STATIC_LIBRARY_SUFFIX
  - CMAKE_SHARED_MODULE_SUFFIX
  - CMAKE_SHARED_LIBRARY_SUFFIX
  - CMAKE_EXECUTABLE_SUFFIX
  - CMAKE__POSTFIX

But it is not enought. CMAKE__POSTFIX changes suffix only for dll
and lib files. But not for exe file.

Also I played with _OUTPUT_NAME. It solves my problem but I have to
change this property for all my projects. It is not obvious in my case. I
have too much projects.

Question: How can I setup suffixes for every configuration in one place?

Regards,
Dima
___
Powered by www.kitware.com

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

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

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

Re: [CMake] exe/a/so sufixes depend on configuration

2009-03-04 Thread Dmytro Ovdiienko
Michael,

Thank you for your replay.

_POSTFIX is a target property. User still have to update all
projects in the source tree.

BTW why CMAKE__POSTFIX applies only for non-executable?

Regards,
Dima

2009/3/4 Michael Jackson 

>• _POSTFIX: Postfix to append to the target file name for
> configuration .
> When building with configuration  the value of this property is
> appended to the target file name built on disk. For non-executable targets,
> this property is initialized by the value of the variable
> CMAKE__POSTFIX if it is set when a target is created. This property
> is ignored on the Mac for Frameworks and App Bundles.
>
>• CMAKE__POSTFIX: Default filename postfix for libraries
> under configuration .
> When a non-executable target is created its _POSTFIX target
> property is initialized with the value of this variable if it is set.
>
>
>
>
> _
> Mike Jackson  mike.jack...@bluequartz.net
> BlueQuartz Softwarewww.bluequartz.net
> Principal Software Engineer      Dayton, Ohio
>
>
>
> On Mar 4, 2009, at 10:37 AM, Dmytro Ovdiienko wrote:
>
>  Michael,
>>
>> RELEASE_OUTPUT_NAME/DEBUG_OUTPUT_NAME properties are the only way to do
>> this. But I have to set these properties for every project (I have 36
>> projects). Noo.. I'm too lazy to do this :)
>>
>> I beleive there is a property like CMAKE__POSTFIX to change suffix
>> for executable.
>>
>> 2009/3/4 Michael Jackson 
>> I wrote/tweaked a Tiff cmake build system, this is what I use:
>>
>> IF (BUILD_SHARED_LIBS)
>>   IF (WIN32 AND NOT MINGW)
>>   SET(LIB_RELEASE_NAME "tiffdll")
>>   SET(LIB_DEBUG_NAME "tiffdll_D")
>>   ELSE (WIN32 AND NOT MINGW)
>>   SET(LIB_RELEASE_NAME "tiff")
>>   SET(LIB_DEBUG_NAME "tiff_debug")
>>   ENDIF(WIN32 AND NOT MINGW)
>> ELSE (BUILD_SHARED_LIBS)
>>   IF (WIN32 AND NOT MINGW)
>>   SET(LIB_RELEASE_NAME "libtiff")
>>   SET(LIB_DEBUG_NAME "libtiff_D")
>>   ELSE (WIN32 AND NOT MINGW)
>>   SET(LIB_RELEASE_NAME "tiff")
>>   SET(LIB_DEBUG_NAME "tiff_debug")
>>   ENDIF(WIN32 AND NOT MINGW)
>> ENDIF (BUILD_SHARED_LIBS)
>>
>> ADD_LIBRARY(tiff ${LIB_TYPE} ${TIFF_SRCS} ${TIFF_HEADERS})
>> TARGET_LINK_LIBRARIES( tiff ${SUPPORT_LIBS} )
>>
>> SET_TARGET_PROPERTIES( tiff
>>   PROPERTIES
>>   DEBUG_OUTPUT_NAME ${LIB_DEBUG_NAME}
>>   RELEASE_OUTPUT_NAME ${LIB_RELEASE_NAME}
>> )
>>
>> #- Use MSVC Naming conventions for Shared Libraries
>> IF (MINGW AND BUILD_SHARED_LIBS)
>>   SET_TARGET_PROPERTIES( tiff
>>   PROPERTIES
>>   IMPORT_SUFFIX ".lib"
>>   IMPORT_PREFIX ""
>>   PREFIX ""
>>   )
>> ENDIF (MINGW AND BUILD_SHARED_LIBS)
>>
>>
>> _
>> Mike Jackson  mike.jack...@bluequartz.net
>> BlueQuartz Softwarewww.bluequartz.net
>> Principal Software Engineer  Dayton, Ohio
>>
>>
>>
>>
>> On Mar 4, 2009, at 10:06 AM, Dmytro Ovdiienko wrote:
>>
>> Hello All,
>>
>> I use CMake to build my project's sources on windows and linux using
>> static and dynamic runtimes.
>>
>> I would like to add information about build configuration to the output
>> file name as suffix.
>>
>> For instance:
>>  - libsome_lib_linux_x32.a - static library "some_lib" for linux 32bit
>>  - some_lib_windows_x64_md.lib - static library "some_lib" for windows
>> 64bit with dynamic release runtime
>>  - some_lib_windows_x62_mtd.lib - static library "some_lib" for windows
>> 32bit with static debug runtime
>>
>> For windows I generate projects with debug and release configurations.
>>
>> Right now I play with
>>  - CMAKE_STATIC_LIBRARY_SUFFIX
>>  - CMAKE_SHARED_MODULE_SUFFIX
>>  - CMAKE_SHARED_LIBRARY_SUFFIX
>>  - CMAKE_EXECUTABLE_SUFFIX
>>  - CMAKE__POSTFIX
>>
>> But it is not enought. CMAKE__POSTFIX changes suffix only for dll
>> and lib files. But not for exe file.
>>
>> Also I played with _OUTPUT_NAME. It solves my problem but I have
>> to change this property for all my projects. It is not obvious in my case. I
>> have too much projects.
>>
>> Question: How can I setup suffixes for every configuration in one place?
>>
>> Regards,
>> Dima
>> ___
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.cmake.org/mailman/listinfo/cmake
>>
>>
>>
>
___
Powered by www.kitware.com

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

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

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

Re: [CMake] exe/a/so sufixes depend on configuration

2009-03-04 Thread Dmytro Ovdiienko
Michael,

Ya. For now it is the best solution.

Another solution is to generate project files for debug and release
separately.

Regards,
Dima

2009/3/4 Michael Jackson 

> I started another thread to ask for some clarification on those issues.
>
> If I were you I would write a macro that combines everything that I sent
> into a single macro call. That way in each of your projects you could do
> something like:
>
> add_my_executable(exename sources other_stuff debug_postfix)
>
> and then you can get all the benefits of having a _debug post fix on your
> libraries and executables.
>
>
> _
> Mike Jackson  mike.jack...@bluequartz.net
> BlueQuartz Softwarewww.bluequartz.net
> Principal Software Engineer  Dayton, Ohio
>
>
>
> On Mar 4, 2009, at 11:21 AM, Dmytro Ovdiienko wrote:
>
>  Michael,
>>
>> Thank you for your replay.
>>
>> _POSTFIX is a target property. User still have to update all
>> projects in the source tree.
>>
>> BTW why CMAKE__POSTFIX applies only for non-executable?
>>
>> Regards,
>> Dima
>>
>> 2009/3/4 Michael Jackson 
>>   • _POSTFIX: Postfix to append to the target file name for
>> configuration .
>> When building with configuration  the value of this property is
>> appended to the target file name built on disk. For non-executable targets,
>> this property is initialized by the value of the variable
>> CMAKE__POSTFIX if it is set when a target is created. This property
>> is ignored on the Mac for Frameworks and App Bundles.
>>
>>   • CMAKE__POSTFIX: Default filename postfix for libraries
>> under configuration .
>> When a non-executable target is created its _POSTFIX target
>> property is initialized with the value of this variable if it is set.
>>
>>
>>
>>
>>
>> _____
>> Mike Jackson  mike.jack...@bluequartz.net
>> BlueQuartz Softwarewww.bluequartz.net
>> Principal Software Engineer  Dayton, Ohio
>>
>>
>>
>> On Mar 4, 2009, at 10:37 AM, Dmytro Ovdiienko wrote:
>>
>> Michael,
>>
>> RELEASE_OUTPUT_NAME/DEBUG_OUTPUT_NAME properties are the only way to do
>> this. But I have to set these properties for every project (I have 36
>> projects). Noo.. I'm too lazy to do this :)
>>
>> I beleive there is a property like CMAKE__POSTFIX to change suffix
>> for executable.
>>
>> 2009/3/4 Michael Jackson 
>> I wrote/tweaked a Tiff cmake build system, this is what I use:
>>
>> IF (BUILD_SHARED_LIBS)
>>  IF (WIN32 AND NOT MINGW)
>>  SET(LIB_RELEASE_NAME "tiffdll")
>>  SET(LIB_DEBUG_NAME "tiffdll_D")
>>  ELSE (WIN32 AND NOT MINGW)
>>  SET(LIB_RELEASE_NAME "tiff")
>>  SET(LIB_DEBUG_NAME "tiff_debug")
>>  ENDIF(WIN32 AND NOT MINGW)
>> ELSE (BUILD_SHARED_LIBS)
>>  IF (WIN32 AND NOT MINGW)
>>  SET(LIB_RELEASE_NAME "libtiff")
>>  SET(LIB_DEBUG_NAME "libtiff_D")
>>  ELSE (WIN32 AND NOT MINGW)
>>  SET(LIB_RELEASE_NAME "tiff")
>>  SET(LIB_DEBUG_NAME "tiff_debug")
>>  ENDIF(WIN32 AND NOT MINGW)
>> ENDIF (BUILD_SHARED_LIBS)
>>
>> ADD_LIBRARY(tiff ${LIB_TYPE} ${TIFF_SRCS} ${TIFF_HEADERS})
>> TARGET_LINK_LIBRARIES( tiff ${SUPPORT_LIBS} )
>>
>> SET_TARGET_PROPERTIES( tiff
>>  PROPERTIES
>>  DEBUG_OUTPUT_NAME ${LIB_DEBUG_NAME}
>>  RELEASE_OUTPUT_NAME ${LIB_RELEASE_NAME}
>> )
>>
>> #- Use MSVC Naming conventions for Shared Libraries
>> IF (MINGW AND BUILD_SHARED_LIBS)
>>  SET_TARGET_PROPERTIES( tiff
>>  PROPERTIES
>>  IMPORT_SUFFIX ".lib"
>>  IMPORT_PREFIX ""
>>  PREFIX ""
>>  )
>> ENDIF (MINGW AND BUILD_SHARED_LIBS)
>>
>>
>> _
>> Mike Jackson  mike.jack...@bluequartz.net
>> BlueQuartz Softwarewww.bluequartz.net
>> Principal Software Engineer  Dayton, Ohio
>>
>>
>>
>>
>> On Mar 4, 2009, at 10:06 AM, Dmytro Ovdiienko wrote:
>>
>> Hello All,
>>
>> I use CMake to build my project's sources on windows and linux using
>> static and dynamic runtimes.
>>
>> I would like to add information about build configuration to the output
>> file name as suffi

Re: [CMake] exe/a/so sufixes depend on configuration

2009-03-04 Thread Dmytro Ovdiienko
Have to remember why I added suffixes :). Looks like you are right.

2009/3/4 Michael Jackson 

> Actually, if you are on Visual Studio or Xcode then those IDEs will create
> sub-directories for Debug and Release, so in effect, those builds are
> separated. If you are using Makefiles then, yes, create 2 separate build
> directories and run cmake in each one of those setting the CMAKE_BUILD_TYPE
> to either Debug or Release then build.
>
> _
> Mike Jackson  mike.jack...@bluequartz.net
>www.bluequartz.net
>
>
> On Mar 4, 2009, at 11:45 AM, Dmytro Ovdiienko wrote:
>
>  Michael,
>>
>> Ya. For now it is the best solution.
>>
>> Another solution is to generate project files for debug and release
>> separately.
>>
>> Regards,
>> Dima
>>
>> 2009/3/4 Michael Jackson 
>> I started another thread to ask for some clarification on those issues.
>>
>> If I were you I would write a macro that combines everything that I sent
>> into a single macro call. That way in each of your projects you could do
>> something like:
>>
>> add_my_executable(exename sources other_stuff debug_postfix)
>>
>> and then you can get all the benefits of having a _debug post fix on your
>> libraries and executables.
>>
>>
>>
>> _
>> Mike Jackson  mike.jack...@bluequartz.net
>> BlueQuartz Softwarewww.bluequartz.net
>> Principal Software Engineer  Dayton, Ohio
>>
>>
>>
>> On Mar 4, 2009, at 11:21 AM, Dmytro Ovdiienko wrote:
>>
>> Michael,
>>
>> Thank you for your replay.
>>
>> _POSTFIX is a target property. User still have to update all
>> projects in the source tree.
>>
>> BTW why CMAKE__POSTFIX applies only for non-executable?
>>
>> Regards,
>> Dima
>>
>> 2009/3/4 Michael Jackson 
>>  • _POSTFIX: Postfix to append to the target file name for
>> configuration .
>> When building with configuration  the value of this property is
>> appended to the target file name built on disk. For non-executable targets,
>> this property is initialized by the value of the variable
>> CMAKE__POSTFIX if it is set when a target is created. This property
>> is ignored on the Mac for Frameworks and App Bundles.
>>
>>  • CMAKE__POSTFIX: Default filename postfix for libraries
>> under configuration .
>> When a non-executable target is created its _POSTFIX target
>> property is initialized with the value of this variable if it is set.
>>
>>
>>
>>
>>
>> _
>> Mike Jackson  mike.jack...@bluequartz.net
>> BlueQuartz Softwarewww.bluequartz.net
>> Principal Software Engineer  Dayton, Ohio
>>
>>
>>
>> On Mar 4, 2009, at 10:37 AM, Dmytro Ovdiienko wrote:
>>
>> Michael,
>>
>> RELEASE_OUTPUT_NAME/DEBUG_OUTPUT_NAME properties are the only way to do
>> this. But I have to set these properties for every project (I have 36
>> projects). Noo.. I'm too lazy to do this :)
>>
>> I beleive there is a property like CMAKE__POSTFIX to change suffix
>> for executable.
>>
>> 2009/3/4 Michael Jackson 
>> I wrote/tweaked a Tiff cmake build system, this is what I use:
>>
>> IF (BUILD_SHARED_LIBS)
>>  IF (WIN32 AND NOT MINGW)
>> SET(LIB_RELEASE_NAME "tiffdll")
>> SET(LIB_DEBUG_NAME "tiffdll_D")
>>  ELSE (WIN32 AND NOT MINGW)
>> SET(LIB_RELEASE_NAME "tiff")
>> SET(LIB_DEBUG_NAME "tiff_debug")
>>  ENDIF(WIN32 AND NOT MINGW)
>> ELSE (BUILD_SHARED_LIBS)
>>  IF (WIN32 AND NOT MINGW)
>> SET(LIB_RELEASE_NAME "libtiff")
>> SET(LIB_DEBUG_NAME "libtiff_D")
>>  ELSE (WIN32 AND NOT MINGW)
>> SET(LIB_RELEASE_NAME "tiff")
>> SET(LIB_DEBUG_NAME "tiff_debug")
>>  ENDIF(WIN32 AND NOT MINGW)
>> ENDIF (BUILD_SHARED_LIBS)
>>
>> ADD_LIBRARY(tiff ${LIB_TYPE} ${TIFF_SRCS} ${TIFF_HEADERS})
>> TARGET_LINK_LIBRARIES( tiff ${SUPPORT_LIBS} )
>>
>> SET_TARGET_PROPERTIES( tiff
>>  PROPERTIES
>>  DEBUG_OUTPUT_NAME ${LIB_DEBUG_NAME}
>>  RELEASE_OUTPUT_NAME ${LIB_RELEASE_NAME}
>> )
>>
>> #- Use MSVC Naming conventions for Shared Libraries
>> IF (MINGW AND BUILD_SHARED_LIBS)
>>  SET_TARGET_PROPERTIES( tif

[CMake] Colorer scheme

2009-05-16 Thread Dmytro Ovdiienko
Hi All,


Does anybody know where I can download CMake Colorer.take5 scheme?


Regards.

Dima
___
Powered by www.kitware.com

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

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

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

Re: [CMake] Adding program arguments for Debug configuration

2009-05-17 Thread Dmytro Ovdiienko
Alexandru,

Debug parameters are stored to the *.*user file. CMake does not create this
file. Suppose you should add this parameters yourself or store user file
once and copy it to the vcproj folder.

2009/5/17 Alexandru Duţu 

> Hello,
>
> I am new to CMake, and I've been searching the web for a solution to this
> problem also CMake wiki and I found nothing concludent.
> I am using Windows XP SP3 and Visual Studio 2008.
>
> I am trying to include program arguments in debug configuration, without
> arguments I can't debug, normally in VS this is done by going to
> Project/Settings/Debugging/Command Arguments. If I am using a CMake for
> build configuration, by setting the arguments from VS it has no effect, so I
> thought I must include the arguments in CMakeList.txt. From web searching I
> came up with this
>
> "ADD_CUSTOM_COMMAND(
>> TARGET DICOMVolRenderer
>> POST_BUILD
>> COMMAND DICOMVolRenderer -DICOM ${DICOM_DATA} -Clip -CT_Bone
>> DEPENDS DICOMVolRenderer -DICOM ${DICOM_DATA}
>> )"
>
>
> but this just calls my program after every build with my arguments.
> Is there any cmake command for this?
> Is there a solution for this?
>
> Please help me this is bugging me for some days.
>
> Alex
>
> ___
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>
___
Powered by www.kitware.com

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

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

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

[CMake] Howto use targets from several directories in the install clause?

2009-05-19 Thread Dmytro Ovdiienko
Hi all,

I'm trying to write install instruction for my main project (DLL) that
consists from several projects (LIBs). This instruction should copy all
public headers from all dependent targets to the destination directory.

I expected to use following sample but it is erroneous:

install (
TARGETS
utils
system
types
PUBLIC_HEADER DESTINATION ${${PROJECT_NAME}_BINARY_DIR}/install/headers
)


So, I've written code like following. It works but it is little ugly.

get_target_property( public_headers utils PUBLIC_HEADER )
install( FILES ${public_headers} DESTINATION
${${PROJECT_NAME}_BINARY_DIR}/install/headers )

get_target_property( public_headers system PUBLIC_HEADER )
install( FILES ${public_headers} DESTINATION
${${PROJECT_NAME}_BINARY_DIR}/install/headers )

get_target_property( public_headers types PUBLIC_HEADER )
install( FILES ${public_headers} DESTINATION
${${PROJECT_NAME}_BINARY_DIR}/install/headers )



The question is how to make first snippet worked?


Thanks.

Dima
___
Powered by www.kitware.com

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

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

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

Re: [CMake] Howto use targets from several directories in the install clause?

2009-05-20 Thread Dmytro Ovdiienko
Hello Alexander,

Thank you for your reply.

I've made changes as you suggested. It works for now. But IMHO it is
incorrect.  Only DLL root project "knows" all details of installation but
not sub-project.

What if I have several projects based on the same sub-projects? They have
different installation path.

Regards.

Dima

2009/5/19 Alexander Neundorf 

> On Tuesday 19 May 2009, Dmytro Ovdiienko wrote:
> > Hi all,
> >
> > I'm trying to write install instruction for my main project (DLL) that
> > consists from several projects (LIBs). This instruction should copy all
> > public headers from all dependent targets to the destination directory.
> >
> > I expected to use following sample but it is erroneous:
> >
> > install (
> > TARGETS
> > utils
> > system
> > types
> > PUBLIC_HEADER DESTINATION
> ${${PROJECT_NAME}_BINARY_DIR}/install/headers
> > )
>
> I think you have to write the install() command for a target in the
> directory
> where the target is created. I think installing them from a different
> CMakeLists.txt is not supported.
>
>
> Alex
>
___
Powered by www.kitware.com

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

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

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

Re: [CMake] Linking object file with executable

2009-05-20 Thread Dmytro Ovdiienko
Hi Ankit.


Did you try TARGET_LINK_LIBRARIES?

TARGET_LINK_LIBRARIES( myexe ${myobj} )

2009/5/19 ankit jain 

> Hi all,
>
> My Cmakelists contains:
>
> set(myobj  ${CMAKE_CURRENT_SOURCE_DIR}/../objfolder/myfile.obj)
> add_executable(myexe  main.c ${myobj})
>
> This myfile.obj object file is generated while building objfolder before
> creating this executable
>
> Now on building this executable i got a warning:
>
> main.obj: warning: earlier declaration of a function f1() found in
> myfile.obj: second definition ignored..
>
> This means it is taking the f1() function from myfile.obj but i want f1()
> function to be taken from main.obj..
>
> What to do?
>
> Also it is imp. to link this myfile.obj file to myexe  executable since it
> depends on other functions of this object file..
> So this object file has to be there.
> Just tell me how function f1() can be taken from main.c rahter than from
> myfile.obj evenif it still gives warning as:
>
> myfile.obj:warning: earlier definition of function f1() found in main.c
> (since if it takes f1() from main.c): second def. ignored
>
> Regards-
> Ankit Jain
>
>
>
> ___
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>
___
Powered by www.kitware.com

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

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

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

Re: [CMake] Linking object file with executable

2009-05-20 Thread Dmytro Ovdiienko
Ankit,

You have to explain CMake how to handle "*.obj" files.
Find emails how to add ASM support. They should help you.

Regards.

Dima



2009/5/20 ankit jain 

>
>
> 2009/5/20 Dmytro Ovdiienko 
>
>> Hi Ankit.
>>
>>
>> Did you try TARGET_LINK_LIBRARIES?
>>
>> TARGET_LINK_LIBRARIES( myexe ${myobj} )
>
>
> It gives error as myfile.obj.lib not found..
> Since it is not library it is not valid to give like this...
>
> Ankit
>
>
>>
>>
>> 2009/5/19 ankit jain 
>>
>>> Hi all,
>>>
>>> My Cmakelists contains:
>>>
>>> set(myobj  ${CMAKE_CURRENT_SOURCE_DIR}/../objfolder/myfile.obj)
>>> add_executable(myexe  main.c ${myobj})
>>>
>>> This myfile.obj object file is generated while building objfolder before
>>> creating this executable
>>>
>>> Now on building this executable i got a warning:
>>>
>>> main.obj: warning: earlier declaration of a function f1() found in
>>> myfile.obj: second definition ignored..
>>>
>>> This means it is taking the f1() function from myfile.obj but i want f1()
>>> function to be taken from main.obj..
>>>
>>> What to do?
>>>
>>> Also it is imp. to link this myfile.obj file to myexe  executable since
>>> it depends on other functions of this object file..
>>> So this object file has to be there.
>>> Just tell me how function f1() can be taken from main.c rahter than from
>>> myfile.obj evenif it still gives warning as:
>>>
>>> myfile.obj:warning: earlier definition of function f1() found in main.c
>>> (since if it takes f1() from main.c): second def. ignored
>>>
>>> Regards-
>>> Ankit Jain
>>>
>>>
>>>
>>> ___
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Please keep messages on-topic and check the CMake FAQ at:
>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.cmake.org/mailman/listinfo/cmake
>>>
>>
>>
>
___
Powered by www.kitware.com

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

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

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

[CMake] CMakeVSXXFindMake.cmake should use VSXXCOMNTOOLS variable

2009-05-28 Thread Dmytro Ovdiienko
Hello,

CMake 2.6.4 cannot generate project for VS2008 Win32 on the following
environment:

- Windows Serevr 2003 Enterprise x64
- VS2003  (32bit)
- VS2005 (32bit)
- VS2008 (32bit)

It uses VS2003 toolset instead VS2008 because of the order of the
directories in the CMakeVS9FindMake.cmake.

I changed this file like following:

FIND_PROGRAM(CMAKE_MAKE_PROGRAM
  NAMES VCExpress devenv
  PATHS
  "$ENV{VS90COMNTOOLS}/../IDE"
  )
MARK_AS_ADVANCED(CMAKE_MAKE_PROGRAM)
SET(MSVC90 1)
SET(MSVC_VERSION 1500)


And now it works well. Suppose we should not use directories in this file.
The best way is to use registry or environment variable.

Regards.

Dima
___
Powered by www.kitware.com

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

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

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

Re: [CMake] Problem with circular dependencies

2009-05-28 Thread Dmytro Ovdiienko
Hello Tyler,

Please find my comments below.

2009/5/28 Tyler Roscoe 

> On Thu, May 28, 2009 at 08:56:04PM +0300, Dmytro Ovdiienko wrote:
> > 1. We have two projects A and B.
> > 2. Project A is stored to /A
> > 3. Project B is stored to /B
> > 4. Project A depends on B.
> > 5. Project B depends on A. (please don't ask me why:) )
> > 6. There is CMakeLists.txt in the 
>
> If A and B really depend on each other, I don't know how you would ever
> expect to build them, nor how you would expect CMake to handle this
> case.
>

That was just a sample. CMake  can build it correctly, if you specify full
path to the include directlry.

If you root CMakeLists.txt declares ROOT_PRJ you can write following in the
A project.

INCLUDE_DIRECTORIES(
  ${ROOT_PRJ_SOURCE_DIR}/B
 )

And following in the B project

INCLUDE_DIRECTORIES(
  ${ROOT_PRJ_SOURCE_DIR}/A
 )


>
> But from your Lists below it appears that they don't really depend on
> one another, in a "target A must be built before target B" sense, but
> simply that they use headers from each other's source directories?
>

A and B are static libraries. The order static libraries building has no
mater.



> > #
> > # Project A
> > #
> > SET (PROJECT_NAME A )
> > PROJECT (${PROJECT_NAME})
> >
> > INCLUDE_DIRECTORIES(
> >   ${B_SOURCE_DIR}
> > )
> >
> > FILE (GLOB ${PROJECT_NAME}_SOURCE_LIST
> > *.cpp
> > )
> >
> > ADD_LIBRARY (${PROJECT_NAME} ${${PROJECT_NAME}_SOURCE_LIST})
> >
> > #
> > # Project B
> > #
> > SET (PROJECT_NAME B )
> > PROJECT (${PROJECT_NAME})
> >
> > INCLUDE_DIRECTORIES(
> >   ${A_SOURCE_DIR}
> > )
> >
> > FILE (GLOB ${PROJECT_NAME}_SOURCE_LIST
> > *.cpp
> > )
> >
> > ADD_LIBRARY (${PROJECT_NAME} ${${PROJECT_NAME}_SOURCE_LIST})
> >
> >
> > And now we generate the project files and check Additional Includes
> > Directories of the A project.
> >
> > Expected it is equal to /B.
> > But in fact it is empty.
>
> Is ${B_SOURCE_DIR} defined in the CMakeLists for project A?
>

It is defined if B folder is processed before A folder. But then
A_SOURCE_DIR is not defined in the B project (circular dependency)


>
> > The other side of this problem is you have to write ADD_SUBDIRECTORY
> > commands in specific order. IMHO it is inconvenient.
>
> CMakeLists are essentially a scripting language, so of course order
> matters. What would you propose instead?
>

But... why does TARGET_LINK_LIBRARIES work correctly? You can pass not
loaded-yet project name to TARGET_LINK_LIBRARIES.


>
> tyler
>
___
Powered by www.kitware.com

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

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

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

Re: [CMake] Problem with circular dependencies

2009-05-28 Thread Dmytro Ovdiienko
Michael,

I agree with the first part and not agree with the second part of your
message.
Libraries (*.lib)  are stored to the different folders and compiler will not
find A to link it into B without full path. So CMake should provide linker
with the full path of the A and B libraries. To calculate full path CMake
should process project file.

2009/5/28 Michael Jackson 

>
> On May 28, 2009, at 3:03 PM, Dmytro Ovdiienko wrote:
>
>
>> > The other side of this problem is you have to write ADD_SUBDIRECTORY
>> > commands in specific order. IMHO it is inconvenient.
>>
>> CMakeLists are essentially a scripting language, so of course order
>> matters. What would you propose instead?
>>
>> But... why does TARGET_LINK_LIBRARIES work correctly? You can pass not
>> loaded-yet project name to TARGET_LINK_LIBRARIES.
>>
>
>
> Remember that you are passing the names of _libraries_ to
> "target_link_libraries" and not the names of Projects. The fact that it
> might work just means that you named your libraries the same as the project
> name.
>
> _
> Mike Jackson  mike.jack...@bluequartz.net
> BlueQuartz Softwarewww.bluequartz.net
> Principal Software Engineer  Dayton, Ohio
>
>
>
> ___
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>
___
Powered by www.kitware.com

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

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

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

Re: [CMake] Problem with circular dependencies

2009-05-28 Thread Dmytro Ovdiienko
Tyler,

Please find my comments below.

2009/5/29 Tyler Roscoe 

> On Thu, May 28, 2009 at 10:03:11PM +0300, Dmytro Ovdiienko wrote:
> > That was just a sample. CMake  can build it correctly, if you specify
> full
> > path to the include directlry.
> >
> > If you root CMakeLists.txt declares ROOT_PRJ you can write following in
> the
> > A project.
> >
> > INCLUDE_DIRECTORIES(
> >   ${ROOT_PRJ_SOURCE_DIR}/B
> >  )
> >
> > And following in the B project
> >
> > INCLUDE_DIRECTORIES(
> >   ${ROOT_PRJ_SOURCE_DIR}/A
> >  )
>
> This is how I would do it. Either this, or just define A_SOURCE_DIR and
> B_SOURCE_DIR in your top-level CMakeLists.
>

I prefer encapsulation of all library related information into the library.
Only library know where it is located, where are public headers are located,
where lib file is located. The way you proposed violates this encapsulation.

Do you use .NET? Do you know how it is easy to use assemblies. There are no
lib files, no headers. You just provide linker with one DLL file. It
contains all needed information to build project.

I want to use libraries like assembly. Target can store all information
about PUBLIC_HEADERS and lib files. You should just say "Library A depends
on library B". CMake should extract information about header files and lib
files from A and place it to B.



>
> > A and B are static libraries. The order static libraries building has no
> > mater.
>
> Not true. Typically I interpret "dependencies" in this context to
> describe a situation where source files in B rely on symbols in libA.
> Therefore, libA must be available so that we can compile (and link)
> libB. In this situation, libA obviously must be built before libB.
>

Yeah, source files of the B depends on symbols from libA. But linker do not
need to resolve all dependencies while it creates lib files. Sure, we are
not talking about cases when libA are linked directly to libB.

>
> > It is defined if B folder is processed before A folder. But then
> > A_SOURCE_DIR is not defined in the B project (circular dependency)
>
> Ok, now I see what you mean. As noted above, I would move the dependency
> up to the top level to prevent this loop.
>
> I still don't understand how you would expect CMake to handle this
> situation.
>

I expected CMake to replace B_SOURCE_DIR with /B and A_SOURCE_DIR with
/A. Thats all.


>
> > But... why does TARGET_LINK_LIBRARIES work correctly? You can pass not
> > loaded-yet project name to TARGET_LINK_LIBRARIES.
>
> I think my favorite pop superstar-nee-software developer Mike Jackson
> already addressed this point (just because libs and targets happen to
> have the same name doesn't mean that they are the same concept).
>
> tyler
>


Best regards

Dima
___
Powered by www.kitware.com

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

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

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

Re: [CMake] Problem with circular dependencies

2009-05-28 Thread Dmytro Ovdiienko
Agree

2009/5/29 David Cole 

> On Thu, May 28, 2009 at 6:06 PM, Tyler Roscoe  wrote:
>
>> Well as you concisely stated at the beginning of this discussion, you
>> have a circular dependency. Software is bad at handling circular
>> dependencies, so it is your job as the human to jump in and decide how
>> to break it up. We have discussed a number of strategies for doing this.
>
>
> I'm not going to question "why?" -- after all, you told us not to :-)
>
> However, I will say that the solution to this is simply to eliminate the
> circular dependency.
>
> If, in fact, A cannot be linked without B and B cannot be linked without A,
> then A and B are in reality a tightly-coupled single inseparable entity.
> So... rather than struggling with this and trying to shove a square peg into
> a round hole, simply refactor the square peg into a round peg and it will
> fit nicely.
>
> Maybe it is easier for me to say this than for you to actually do it, but
> nevertheless, I do not think you can refute the logic that says : A and B
> are, in reality, "AB" . so stop trying to treat them as separate
> entities.
>
> Merge/glue them together and nobody will have to think about this problem
> again...
>
> Just my opinion... not even 2 cents worth,
>   :-)   David
>
>
___
Powered by www.kitware.com

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

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

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

Re: [CMake] Problem with circular dependencies

2009-05-28 Thread Dmytro Ovdiienko
Hello Tyler,

Please find my comments below.

2009/5/29 Tyler Roscoe 

> On Fri, May 29, 2009 at 01:45:45AM +0430, Dmytro Ovdiienko wrote:
> > I prefer encapsulation of all library related information into the
> library.
> > Only library know where it is located, where are public headers are
> located,
> > where lib file is located. The way you proposed violates this
> encapsulation.
>
> Fair enough. What I actually do is I have a separate file CMakeVars.txt
> where I define variable (such as source directories). This file is
> include()d both by the subproject (libA) and by any top-level projects
> that add_subdirectory() that subproject.
>

So, you have to support additional file. You should remove extra variable
from that CMakeLists.txt after you removed project. You have to add variable
after you add new project. It is possible to get inconsistant file, so far.


>
> You could do the same thing with [set|get]_target_properties(). I do
> this in a few spots where my CMakeVars pattern doesn't work.
>

Did not get. What do you mean?


>
> This doesn't help with your ordering problem.
>

Yeah. By David Cole I should merge A and B. But support right ordering of 30
projects... that may be not trivial.


>
> > I expected CMake to replace B_SOURCE_DIR with /B and A_SOURCE_DIR
> with
> > /A. Thats all.
>
> Well as you concisely stated at the beginning of this discussion, you
> have a circular dependency. Software is bad at handling circular
> dependencies, so it is your job as the human to jump in and decide how
> to break it up. We have discussed a number of strategies for doing this.
>
> tyler
>
___
Powered by www.kitware.com

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

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

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

Re: [CMake] nightly builds with VS projects

2009-05-29 Thread Dmytro Ovdiienko
Benne,

Try to build with "devenv.com".

2009/5/28 Benne, Kyle 

>  Is anyone using msbuild to run their nightly builds with Visual Studio
> solutions generated by CMake?  I can’t get the tests to run or the results
> uploaded using the command line tool.  It works fine if I build the Nightly
> or Experimental targets from within the IDE.  Perhaps I am using the wrong
> approach?  I have tried variations of the command line “msbuild
> my_project.sln /target:Experimental”.
>
>
>
> Thanks,
>
>
>
> Kyle
>
>
>
> ___
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>
___
Powered by www.kitware.com

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

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

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

Re: [CMake] Linux In-the-source Build multiple modes without swithing

2009-06-19 Thread Dmytro Ovdiienko
Charlie,

Move all your input data files to the resource folder and add following to
the end of CMakeLists.txt

##
# Post-build steps
##

add_custom_command(
TARGET ${PROJECT_NAME}

POST_BUILD
COMMAND ${CMAKE_COMMAND} ARGS -E copy_directory
${${PROJECT_NAME}_SOURCE_DIR}/resources ${${PROJECT_NAME}_BINARY_DIR}
)

PROJECT_NAME is a variable that holds name of the target.

After all your executale files will work correctly from VS and on Linux.

BTW, how about to add to CMake posibility to create symbolic/hard links?

2009/6/19 Charlie Sun 

> Because I would need to run the test using ctest, and the test cases have
> hard-coded and relative paths configured. If i do an out-of-source build.
> Some test cases would fail.
> I am also building the project on windows Visual studio, which does not
> have the problem with in-the-source. it will put object files in different
> folders (release/debug).
> Therefore, I don't know why it won't work in that way on Linux.
>
> Thanks and regards,
>
> Charlie
>
> On Wed, Jun 17, 2009 at 11:39 AM, Bill Hoffman 
> wrote:
>
>> Charlie Sun wrote:
>>
>>> Hi,
>>> I'm trying to do a linux  build with both release and debug mode. In
>>> stead of builing out of source as indicated on the FAQ 4.15, I really need
>>> to do in the source build. currently, if I do a release build and then a
>>> debug build and then another release build. It will actually rebuild the
>>> release and forgets the previous release build. Is it because cmake is only
>>> generating one set of objective files when doing in-the-source, either
>>> release or debug? Is there a way to have both? Any help is greatly
>>> appreciated!
>>>
>>> Regards,
>>>
>>
>> The only way to do what you want is to use out of source builds.  Why do
>> you have to do in-source builds?
>>
>> -Bill
>>
>
>
> ___
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>
___
Powered by www.kitware.com

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

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

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