Re: [CMake] Include directories for C compile command
Hello Glenn and thanks,
I found out yesterday the method you describe works. I was trying to use
include_directories() before, but unfortunately the statement was after any
add_directory() statement and it was a matter of scope (what other
variable/property updates add_directory() does?).
It works now, but still I'm wondering if there is a method of doing the same
thing at module level (leaf CMakeLists.txt files) and propagate the updates
upwards in directory hierarchy.
Thanks again,
Andrei
On Wed, Aug 3, 2011 at 8:10 PM, Glenn Coombs wrote:
> Have you tried using the include_directories() command ? In your top level
> CMakeLists.txt add a line like this:
>
> include_directories(SWC1 SWC2 SWC3 Common)
>
> before you do any add_subdirectory() commands.
>
> Does that not add the appropriate -Ixxx flags to the compile command ? It
> does for me but I'm using Visual Studio and gcc rather than an embedded
> compiler.
>
> On 3 August 2011 07:25, Andrei Buzgan wrote:
>
>> Hello everyone,
>>
>> I'm trying to set up an environment for building a pre-existing medium
>> sized embedded software project, by using CMake 2.8 and MinGW. The compiler
>> kit is specific for the target microcontroller and contains C compiler,
>> assembler, linker, all different executables.
>>
>> I do have some restrictions:
>> The project structure looks like this:
>> Sources
>> |-- SWC1
>> ||-- swc1.c
>> ||-- swc1.h
>> ||--CMakeLists.txt
>> |-- SWC2
>> ||-- swc2_a.c
>> ||-- swc2_b.c
>> ||-- swc2.h
>> ||--CMakeLists.txt
>> |-- COMMON
>> ||-- config1.h
>> ||-- config2.h
>> ||--CMakeLists.txt
>> |-- UNUSED_DIR
>> |-- SWC3
>> ||-- swc3.obj
>> ||-- swc3.h
>>
>>
>> - I cannot change the directory structure of the project (i can add but i
>> must not move files around)
>>
>> - each SW module (component) has it own files including interface headers
>> in it's own directory
>> (SW component SWC1 resides in folder SWC1 and contains a source file and a
>> header file)
>>
>> - SW modules may be interfaced with any other module
>> (swc1.c may include swc2.h...)
>>
>> - There are common header files with project scope definitions and
>> configurations which reside in their own directory too
>> (both swc1.c and swc2.c may include headers config1.h and config2.h)
>>
>> - The SW has more variants, some variants use different C source files for
>> a specific SW component but the sources reside in the same directory and
>> interface headers are common for all variants.
>> (For SW variant A the SW component SWC2 uses swc2_a.c source file, for SW
>> variant B it uses swc2_b.c file)
>>
>> - Some SW components are precompiled and provided as object files together
>> with the interface header (SWC3)
>>
>> *These being the conditions, i couldn't manage to gather the relevant
>> folders in order to correctly create the build object command *where
>> "flags" like -I -I ... are expected in order to look
>> for included headers. Due to mixed source-precompiled objects I chose to
>> define each component as a static library (add_library(...)) in each
>> CMakeLists.txt file and list there the used source files, being able to use
>> conditions for SW variants and basically add different library definitions
>> for each variant. I intend to add the pre-compiled sources as IMPORTED
>> libraries and in the end just link the "libraries" with the specific linker
>> command for linking any object files (but i didn't get there yet!)
>>
>> I'm currently use the default CMAKE_C_COMPILE_OBJECT command
>>-o-c , the compiler
>> ignoring the unknown flags ("-c" in this case). *Without any explicit
>> configuration from my part, it looks like variable contains also a
>> -I directive for the current compiled source file* ( is the
>> same directory where the source files about to be compiled resides).
>>
>> I tried to use "set( CMAKE_INCLUDE_CURRENT_DIR ON )" in each
>> CMakeLists.txt file but variable seems not to be updated this way.
>>
>> I'd like to know if there is an efficient method to build an include
>> directory list in order to pass it to compile flags. It would be very useful
>> to make this in CMakeLists.txt file or link it somehow to add_directory(dir)
>> and use an internal CMake mechanism trying to avoid creating this part of
>> the compiler flags manually in order to be easily maintained in the future.
>>
>> Thanks,
>> Andrei
>>
>>
>>
>>
>> ___
>> 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 m
Re: [CMake] Assembly language support using gcc or gas
Hi,
On Wednesday 03 August 2011, Glenn Coombs wrote:
> I tried changing from ASM to ASM-ATT and that fails like this:
>
> /usr/bin/as -I/user/grc/msvdx-cvsfiles/sim/msvdx-cmake-2.8.5/systemC/src
> -I/user/grc/msvdx-cvsfiles/sim/msvdx-cmake-2.8.5/systemC/src/sysc/kernel
> -DNOMINMAX -DUSE_SIM_NAMESPACE -o
> CMakeFiles/systemc.dir/src/sysc/qt/md/i386.s.o
> /user/grc/msvdx-cvsfiles/sim/msvdx-cmake-2.8.5/systemC/src/sysc/qt/md/i386.
> s /usr/bin/as: unrecognized option `-NOMINMAX'
>
> I really don't think the -I and -D options should be passed through for
> assembler files. They only make sense for C/C++ files. There should be a
> separate variable like CMAKE_ASM_FLAGS that is used instead of
> CMAKE_C_FLAGS or CMAKE_CXX_FLAGS. And maybe there needs to be a change to
> the
> add_definitions() command to allow an optional LANG argument ? Do
> assembers even support preprocessor definitions ?
>
> I was able to get it to work for both 2.8.4 and 2.8.5 with the following
> code:
>
> if(UNIX)
> list(APPEND sources "src/sysc/qt/qt.c")
>
> # see if we are building 32-bit or 64-bit executables
> file(WRITE ${CMAKE_BINARY_DIR}/check_32or64bit.cpp "int main(int argc,
> char *argv[]) { return 8 * sizeof(char *); }\n")
>
> try_run(
> run_result
> compile_result
> ${CMAKE_BINARY_DIR}
> ${CMAKE_BINARY_DIR}/check_32or64bit.cpp
> )
>
> if (${run_result} EQUAL 32)
> list(APPEND sources "src/sysc/qt/md/i386.s")
> if(APPLE)
> set(ASM_SYS_FLAGS "-arch i386")
> else()
> set(ASM_SYS_FLAGS "-32")
> endif()
> else()
> list(APPEND sources "src/sysc/qt/md/iX86_64.s")
> if(APPLE)
> set(ASM_SYS_FLAGS "-arch x86_64")
> else()
> set(ASM_SYS_FLAGS "-64")
> endif()
> endif()
>
> enable_language(ASM-ATT)
>
> set(CMAKE_ASM-ATT_COMPILE_OBJECT "
> ${ASM_SYS_FLAGS} -o ")
> endif()
>
> I'm not sure if this is the recommended way to do this though. I thought
> the documentation said to override CMAKE_ASM-ATT_COMPILE_OBJECT before the
> enable_language() command.
You should not have to override it.
To set flags, there are for every enabled language CMAKE__FLAGS in
the cmake cache, i.e. CMAKE_ASM-ATT_FLAGS in this case.
I tried to reproduce the problem with the attached tiny project, and I don't
get the problem you describe. This is the output:
as-test/b$ /opt/cmake-HEAD/bin/cmake ..
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- The ASM-ATT compiler identification is GNU
-- Found assembler: /usr/bin/as
-- Configuring done
-- Generating done
-- Build files have been written to: /home/alex/src/CMake/build dir/CMake-
git/Tests/Assembler/as-test/b
as-test/b$ make VERBOSE=1
...
Scanning dependencies of target hello
make[2]: Leaving directory `/home/alex/src/CMake/build dir/CMake-
git/Tests/Assembler/as-test/b'
make -f CMakeFiles/hello.dir/build.make CMakeFiles/hello.dir/build
make[2]: Entering directory `/home/alex/src/CMake/build dir/CMake-
git/Tests/Assembler/as-test/b'
/opt/cmake-HEAD/bin/cmake -E cmake_progress_report "/home/alex/src/CMake/build
dir/CMake-git/Tests/Assembler/as-test/b/CMakeFiles" 1
[ 50%] Building C object CMakeFiles/hello.dir/main.c.o
/usr/bin/gcc -DFOO -DBLUB=blub -DBAR=bar -I/opt/include-o
CMakeFiles/hello.dir/main.c.o -c "/home/alex/src/CMake/build dir/CMake-
git/Tests/Assembler/as-test/main.c"
/opt/cmake-HEAD/bin/cmake -E cmake_progress_report "/home/alex/src/CMake/build
dir/CMake-git/Tests/Assembler/as-test/b/CMakeFiles" 2
[100%] Building ASM-ATT object CMakeFiles/hello.dir/foo.s.o
/usr/bin/as -I/opt/include-o CMakeFiles/hello.dir/foo.s.o
"/home/alex/src/CMake/build dir/CMake-git/Tests/Assembler/as-test/foo.s"
Linking C executable hello
...
So, here main.c gets all the -D's, and foo.s gets the -I, but not the -D's.
Is that different for you ?
Alex
as-test.tar.gz
Description: application/compressed-tar
___
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] How to installing cmake Config.cmake files under Debian multiarch ?
On 8/3/2011 1:19 PM, Alexander Neundorf wrote:
Is there already a variable which contains the multiarch triplet, so I can do
something like lib/${CMAKE_MULTIARCH_TRIPLET}/... ?
Yes, "CMAKE_LIBRARY_ARCHITECTURE". It contains no slashes and is empty
if there is no architecture choice.
Slightly different question: if a Config.cmake file is installed on a
multiarch debian system, will it also be found if installed in lib/ or lib64/
(i.e. without the multiarch triplet) ?
Yes.
How can lib/cmake/Foo/FooConfig.cmake know where the include dir is ?
If someone uses absolute install locations he/she better use the installed
package only from those locations. The packager that creates a binary
installer better use relative locations. This is no different than it
was before multiarch or GNUInstallDirs.
We didn't see a way how to do this, so we decided those directories should not
be in the cache, so we can be sure they are never absolute.
if(IS_ABSOLUTE "${CMAKE_INSTALL_LIBDIR}")
message(FATAL_ERROR "We do not support this.")
endif()
-Brad
___
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] How to installing cmake Config.cmake files under Debian multiarch ?
On Wednesday 03 August 2011, Brad King wrote:
> On 8/3/2011 11:41 AM, Alexander Neundorf wrote:
> > On Tuesday 02 August 2011, Hendrik Sattler wrote:
> >> If you use cmake 2.8.5, you can use GNUInstalldirs.cmake and let the
> >> user specify the multiarch directory to install in (or solve it once in
> >> that cmake module).
> >
> > You mean having the user adjust the lib install dir correctly manually ?
> > Hmm, I think it is not realistic to expect that users will know about
> > that. There must be a way to do this so that it is works automatically,
> > at least so that a cmake on the same system will find what was
> > installed.
>
> See discussion here on why we can't transform the install() DESTINATION
> options magically:
>
>http://www.cmake.org/Bug/view.php?id=11964#c25884
>
> The conclusion was that user code that intends to support such cases
> must reference a variable in its install destinations.
Yes, that's fine.
Is there already a variable which contains the multiarch triplet, so I can do
something like lib/${CMAKE_MULTIARCH_TRIPLET}/... ?
Slightly different question: if a Config.cmake file is installed on a
multiarch debian system, will it also be found if installed in lib/ or lib64/
(i.e. without the multiarch triplet) ?
> The GNUInstallDirs module provides a good variable to reference:
>
>
> http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/GNUInstallDirs.cmake;
> hb=v2.8.5#l71
>
>install(... DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake/Foo)
That's mostly fine, but I see an issue with this, again for the Config.cmake
files.
We discussed this in Randa with packagers from SUSE, Debian and FreeBSD. They
agreed that they don't see any reason to have the include in a different
prefix than the libdir.
So we decided to recommend _not_ to put LIBDIR and INCLUDEDIR in the cache
(this is still done with kdelibs4, but I think this was a bad decision back
then).
Reason: when I install a FooConfig.cmake file, I expect it not only to set
FOO_LIBRARY, but also FOO_INCLUDE_DIR.
How can lib/cmake/Foo/FooConfig.cmake know where the include dir is ?
If the include install dir was a relative path at build time, and if the lib
install dir was a relative path at build time, then the FooConfig.cmake can
know how to get from its own location to the installed include dir.
That's the good case.
Now, if the include and/or lib install directories are in the cache, the user
can set them to absolute locations.
Under Windows this can also be under different drive letters.
What we are doing with kdelibs4 is to put the complete absolute path in the
FooConfig.cmake file. This is fine for Linux, but sucks for Windows.
Because there, the user wants to decide at install time (of a binary package),
where and on which drive he installs the package.
Let's say he decides for d:/mystuff/, but the incdir was set to the absolute
path c:/include and the libdir to the absolute path c:/lib, how can the
FooConfig.cmake which will be in d:/mystuff/lib/cmake/Foo/ figure out that the
include dir is now d:/mystuff/include instead of c:/include ?
We didn't see a way how to do this, so we decided those directories should not
be in the cache, so we can be sure they are never absolute.
What is in the cache is a suffix for the lib install dir.
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] Include directories for C compile command
Have you tried using the include_directories() command ? In your top level
CMakeLists.txt add a line like this:
include_directories(SWC1 SWC2 SWC3 Common)
before you do any add_subdirectory() commands.
Does that not add the appropriate -Ixxx flags to the compile command ? It
does for me but I'm using Visual Studio and gcc rather than an embedded
compiler.
On 3 August 2011 07:25, Andrei Buzgan wrote:
> Hello everyone,
>
> I'm trying to set up an environment for building a pre-existing medium
> sized embedded software project, by using CMake 2.8 and MinGW. The compiler
> kit is specific for the target microcontroller and contains C compiler,
> assembler, linker, all different executables.
>
> I do have some restrictions:
> The project structure looks like this:
> Sources
> |-- SWC1
> ||-- swc1.c
> ||-- swc1.h
> ||--CMakeLists.txt
> |-- SWC2
> ||-- swc2_a.c
> ||-- swc2_b.c
> ||-- swc2.h
> ||--CMakeLists.txt
> |-- COMMON
> ||-- config1.h
> ||-- config2.h
> ||--CMakeLists.txt
> |-- UNUSED_DIR
> |-- SWC3
> ||-- swc3.obj
> ||-- swc3.h
>
>
> - I cannot change the directory structure of the project (i can add but i
> must not move files around)
>
> - each SW module (component) has it own files including interface headers
> in it's own directory
> (SW component SWC1 resides in folder SWC1 and contains a source file and a
> header file)
>
> - SW modules may be interfaced with any other module
> (swc1.c may include swc2.h...)
>
> - There are common header files with project scope definitions and
> configurations which reside in their own directory too
> (both swc1.c and swc2.c may include headers config1.h and config2.h)
>
> - The SW has more variants, some variants use different C source files for
> a specific SW component but the sources reside in the same directory and
> interface headers are common for all variants.
> (For SW variant A the SW component SWC2 uses swc2_a.c source file, for SW
> variant B it uses swc2_b.c file)
>
> - Some SW components are precompiled and provided as object files together
> with the interface header (SWC3)
>
> *These being the conditions, i couldn't manage to gather the relevant
> folders in order to correctly create the build object command *where
> "flags" like -I -I ... are expected in order to look
> for included headers. Due to mixed source-precompiled objects I chose to
> define each component as a static library (add_library(...)) in each
> CMakeLists.txt file and list there the used source files, being able to use
> conditions for SW variants and basically add different library definitions
> for each variant. I intend to add the pre-compiled sources as IMPORTED
> libraries and in the end just link the "libraries" with the specific linker
> command for linking any object files (but i didn't get there yet!)
>
> I'm currently use the default CMAKE_C_COMPILE_OBJECT command
>-o-c , the compiler
> ignoring the unknown flags ("-c" in this case). *Without any explicit
> configuration from my part, it looks like variable contains also a
> -I directive for the current compiled source file* ( is the
> same directory where the source files about to be compiled resides).
>
> I tried to use "set( CMAKE_INCLUDE_CURRENT_DIR ON )" in each CMakeLists.txt
> file but variable seems not to be updated this way.
>
> I'd like to know if there is an efficient method to build an include
> directory list in order to pass it to compile flags. It would be very useful
> to make this in CMakeLists.txt file or link it somehow to add_directory(dir)
> and use an internal CMake mechanism trying to avoid creating this part of
> the compiler flags manually in order to be easily maintained in the future.
>
> Thanks,
> Andrei
>
>
>
>
> ___
> 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] Assembly language support using gcc or gas
I tried changing from ASM to ASM-ATT and that fails like this:
/usr/bin/as -I/user/grc/msvdx-cvsfiles/sim/msvdx-cmake-2.8.5/systemC/src
-I/user/grc/msvdx-cvsfiles/sim/msvdx-cmake-2.8.5/systemC/src/sysc/kernel
-DNOMINMAX -DUSE_SIM_NAMESPACE -o
CMakeFiles/systemc.dir/src/sysc/qt/md/i386.s.o
/user/grc/msvdx-cvsfiles/sim/msvdx-cmake-2.8.5/systemC/src/sysc/qt/md/i386.s
/usr/bin/as: unrecognized option `-NOMINMAX'
I really don't think the -I and -D options should be passed through for
assembler files. They only make sense for C/C++ files. There should be a
separate variable like CMAKE_ASM_FLAGS that is used instead of CMAKE_C_FLAGS
or CMAKE_CXX_FLAGS. And maybe there needs to be a change to the
add_definitions() command to allow an optional LANG argument ? Do assembers
even support preprocessor definitions ?
I was able to get it to work for both 2.8.4 and 2.8.5 with the following
code:
if(UNIX)
list(APPEND sources "src/sysc/qt/qt.c")
# see if we are building 32-bit or 64-bit executables
file(WRITE ${CMAKE_BINARY_DIR}/check_32or64bit.cpp "int main(int argc,
char *argv[]) { return 8 * sizeof(char *); }\n")
try_run(
run_result
compile_result
${CMAKE_BINARY_DIR}
${CMAKE_BINARY_DIR}/check_32or64bit.cpp
)
if (${run_result} EQUAL 32)
list(APPEND sources "src/sysc/qt/md/i386.s")
if(APPLE)
set(ASM_SYS_FLAGS "-arch i386")
else()
set(ASM_SYS_FLAGS "-32")
endif()
else()
list(APPEND sources "src/sysc/qt/md/iX86_64.s")
if(APPLE)
set(ASM_SYS_FLAGS "-arch x86_64")
else()
set(ASM_SYS_FLAGS "-64")
endif()
endif()
enable_language(ASM-ATT)
set(CMAKE_ASM-ATT_COMPILE_OBJECT "
${ASM_SYS_FLAGS} -o ")
endif()
I'm not sure if this is the recommended way to do this though. I thought
the documentation said to override CMAKE_ASM-ATT_COMPILE_OBJECT before the
enable_language() command. If I do that then I get the -I and -D flags back
and my ASM_SYS_FLAGS variable is ignored. Is there a cleaner way to do this
or is my current solution okay ?
2011/8/2 Alexander Neundorf
> Hi,
>
> On Tuesday 02 August 2011, Glenn Coombs wrote:
> > Previously with cmake 2.8.4 we were using these lines to compile an
>
> with 2.8.5 there was a major rework of the assembler support (and now it
> finally does not say "Assembler support is experimental" anymore).
> Sorry that this causes inconvenience for you.
>
> If you enable "ASM", you get support for assembler via your C/C++ compiler.
> That's why you get gcc now instead of as.
> If the C/C++ compiler does not support processing assembler files, this
> language can't be enabled.
>
> If you need a "real" assembler, you have to enable the respective assembler
> "dialect". E.g. to get as/gas, you need to enable "ASM-ATT".
> This should work with both versions.
>
> Let me know if this doesn't work for you.
>
> 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] How to installing cmake Config.cmake files under Debian multiarch ?
On 8/3/2011 11:41 AM, Alexander Neundorf wrote:
On Tuesday 02 August 2011, Hendrik Sattler wrote:
If you use cmake 2.8.5, you can use GNUInstalldirs.cmake and let the user
specify the multiarch directory to install in (or solve it once in that
cmake module).
You mean having the user adjust the lib install dir correctly manually ?
Hmm, I think it is not realistic to expect that users will know about that.
There must be a way to do this so that it is works automatically, at least so
that a cmake on the same system will find what was installed.
See discussion here on why we can't transform the install() DESTINATION
options magically:
http://www.cmake.org/Bug/view.php?id=11964#c25884
The conclusion was that user code that intends to support such cases
must reference a variable in its install destinations. The
GNUInstallDirs module provides a good variable to reference:
http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/GNUInstallDirs.cmake;hb=v2.8.5#l71
install(... DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake/Foo)
However, as noted in the comments it still needs to be taught about
multiarch. Even though that it doesn't do it in CMake 2.8.5 the variable
is a cache entry so packagers can fix it at build time.
The find_package command in CMake 2.8.5 is multiarch-aware and will
search the right place under each installation prefix.
-Brad
___
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] How to installing cmake Config.cmake files under Debian multiarch ?
On Tuesday 02 August 2011, Hendrik Sattler wrote:
> Am Dienstag, 2. August 2011, 21:55:16 schrieb Alexander Neundorf:
> > Hi,
> >
> > until recently, I recommended to install Config.cmake files more or less
> > like this:
> >
> > install(FILES FooConfig.cmake DESTINATION lib${LIB_SUFFIX}/cmake/Foo )
> >
> > with LIB_SUFFIX being "64" on systems where this is required.
> >
> > How do I do this on a Debian multiarch system ?
> > How do I know in which directory I should install ?
>
> If you use cmake 2.8.5, you can use GNUInstalldirs.cmake and let the user
> specify the multiarch directory to install in (or solve it once in that
> cmake module).
You mean having the user adjust the lib install dir correctly manually ?
Hmm, I think it is not realistic to expect that users will know about that.
There must be a way to do this so that it is works automatically, at least so
that a cmake on the same system will find what was installed.
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] Gathering up required shared libraries
On Tuesday, August 02, 2011 06:36:45 pm David Cole wrote: > On Tue, Aug 2, 2011 at 8:05 PM, Clinton Stimpson wrote: > > On Aug 2, 2011, at 5:47 PM, Gregory Crosswhite wrote: > >> On 8/2/11 4:32 PM, Clinton Stimpson wrote: > >>> There is no scanning the file system to find which libraries to fix up. > >>> Any libraries used by executables will be considered in the set of > >>> libraries to fix up, regardless of where they are installed (in bin/ > >>> or lib/). Any libraries not found as a dependency can be specified by > >>> the second parameter of fixup_bundle(). Plugins are a typical example > >>> of that, because executables and libraries don't link against plugins. > >> > >> Doh! For some reason I thought I saw that the code was doing that but I > >> see now that I was mistaken. > >> > >>> You don't need to add your libraries to the second parameter. If you > >>> did, you'd have to know them all up front, and that defeats one of the > >>> purpose of BundleUtilities. > >> > >> Sorry, I obviously didn't make it clear that I was referring to > >> libraries that I was not planning on linking the program against --- > >> that is, libraries provided for the benefit of other developers but not > >> actually used by my program. Having said that, discussing this has > >> made me realize that in my case it would probably make more sense for > >> me to link against my own shared library anyway to prevent code from > >> being duplicated in both program and library, so my use case is not as > >> likely as I had been originally imagining. > > > > Oh, so you're also providing libraries for other developers. In that > > case, you do specify them into the second parameter of fixup_bundle(). > > If those libraries have additional dependencies, then BundleUtilities > > could be useful for that. > > > > Clint > > ___ > > 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 > > Let's not lose sight of the intent behind fixup_bundle here. I don't > want to confuse things by trying to make it all things to all people. > > For our purposes, a "bundle" is a relocatable file system entity (a > directory) which contains a set of executables and libraries that > after fixup, are entirely self-contained, referring to each other only > by relative paths, and will work on any compatible OS, regardless of > where they are placed in the target file system. > > On the Mac, this is achieved by copying external libraries "into the > bundle" and fixing up their references. Elsewhere, this is typically > achieved by copying libraries into the same directory with the > executable (on Windows, just works, on Linux, works as long as you use > $ORIGIN RPATH references). > > When you do not have a ".app" directory, and you are not copying into > the same directory with the executable, then the question in my mind > becomes "what exactly is 'the bundle' at this point?" > > With a dir/bin, dir/lib typical Linux style layout, "dir" would be > "the bundle"... > > If we really want to support this, perhaps we need another function to > extend fixup_bundle so that you pass in the bundle's directory, and > its main executable, or a list of executables. Instead of trying to > derive it from just the main executable like we do now. > Ok.. that does sound like a good idea. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com ___ 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] Header and CXX.includecache - how first comes in second
On 08/03/2011 01:07 PM, Mikhail Pridushchenko wrote: > Hello! > > I have a problem with include files dependencies in my C++ project: > iostream system header (for example) is being cached by CMake in > CXX.includecache file for some targets. Also there are no > #include > lines in my sources. > > I wonder if there is any way to figure out where it could come from? > > Thank you. > > -- > Mikhail Pridushchenko Create the preprocessed file like this: cd path/to/build/tree/where/target/is/defined make help # look for an appropriate sourcename.i in the output make sourcename.i # open the file name in the output in a text editor It is important that if your target (e.g. library or executable) is defined in a sub-directory, you have to call the "make help" and "make sourcename.i" commands in the corresponding directory of the build tree. This file is the file as the compiler sees it after preprocessing. You can follow the trace of which file includes what other files. HTH Michael ___ 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] Header and CXX.includecache - how first comes in second
Hello! I have a problem with include files dependencies in my C++ project: iostream system header (for example) is being cached by CMake in CXX.includecache file for some targets. Also there are no #include lines in my sources. I wonder if there is any way to figure out where it could come from? Thank you. -- Mikhail Pridushchenko ___ 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] [cmake-developers] Cross platform test for comparing two text files
2011/8/2 Ali Ghayoor : > Thank you Eric, > > I want use this inside a Cmake file not as a command line, you can call cmake from within a CMake script using execute_process. > so I used the flag of "--compare_files" inside the Cmake file, but it does > not still work. I do not understand what you mean here? PS: please do not drop the list address when replying. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ 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
