Re: [CMake] Enabling C99 in CMake
On 06/26/2011 04:12 PM, Owen Shepherd wrote: On 25/06/2011 07:30, Michael Hertling mhertl...@online.de wrote: On 06/24/2011 04:16 PM, Owen Shepherd wrote: I think the appropriate solution here is a project-specific dialect flag - perhaps one taking options in the GNU format since it seems most familiar. One could perhaps generalise this further - a file-specific dialect flag which defaults to the value of the project-specific flag If there are individual compilers for C89/C99, and a projects needs a C99 one, any dialect flags - project/directory/target/file specific - would be of no use, wouldn't they? Rather, one must specify the C99 compiler if it isn't found automatically by CMake during the initial configuration, and the project might consider to check the compiler's C99 capabilities. Sorry - I should have said property rather than flag. That is, something along the lines of set_target_properties(the_target PROPERTIES C_DIALECT C99) Or set_source_files_properties(myfile.c PROPERTIES C_DIALECT C99) (I'm not entirely sure here whether the source file property should be C_DIALECT or just DIALECT. The language, after all, should be unambiguous at this point) It would then be the responsibility of the Cmake machinery to choose the right compiler and set it up for building code with the given dialect. This would require to configure the entire project *before* the compiler is chosen, and this means that constructs like IF(CMAKE_C_COMPILER_ID STREQUAL ...) or IF(CMAKE_COMPILER_IS_GNUC) wouldn't work anymore. Of course, they're quite useful and necessary if one wants to enable compiler-specific features, so the compiler must be chosen at the very beginning. Moreover, IMO, it's absolutely inevitable that the responsibility for choosing a suitable compiler rests on the user. The fact that CMake usually finds a suitable one automatically - although common and very convenient - should be considered as the exception rather than the rule, at least in multi-compiler setups. Regards, 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
Re: [CMake] Enabling C99 in CMake
On 06/27/2011 06:34 PM, Todd Gamblin wrote: On Jun 24, 2011, at 11:30 PM, Michael Hertling wrote: On 06/23/2011 06:20 PM, Jed Brown wrote: On Thu, Jun 23, 2011 at 17:50, Michael Hertling mhertl...@online.de wrote: You need to use a C99 compiler for your project This is already a problem. C99 introduces new keywords (e.g. restrict) and removes implicit int. It is entirely possible for part of a project to include C89-conforming legacy code that is not valid C99. The use of C99 or C89 should be a file- and directory-level property. That's a really good point and could indeed be very well addressed by a possibility for a project to enable language dialects per directory/ target/file as Todd has asked for in his initial posting. Yep -- After reading all the responses, think my suggestion was insufficient. Just having a variable for the compiler flags isn't enough. Also, I really like the dialects approach here. This has the potential to take care of not only C99, but also C++ *and* Fortran. The Fortran support in CMake could really use this kind of thing, as it would be very helpful to know if particular Fortran compilers support F90, F77, F08, etc. In order to achieve this in a platform/compiler-independent manner, take a look at the attached dialects.patch file, a diff against the Modules directory of CMake 2.8.4. It is not meant as a production-ready solution, but as as proof of concept, and it's restricted to the GNU C compiler, though it should be easily applicable to the other compilers known by CMake. Thanks for making this! First of all, the new Compiler/LanguageDialects.cmake file provides a function __language_dialects() which accepts a language and a paired list of arguments denoting each supported language dialect followed by the flags to enable it. The function sets up the variable CMAKE_LANG_ DIALECTS_INIT containing the list of dialects, and for each dialect a variable CMAKE_LANG_DIALECT_DIALECT_INIT containing the respective flags. The Compiler/GNU-C.cmake file is enhanced to - exemplary - call __language_dialects(C C90 -std=c90 C89 -std=c89 C99 -std=c99 C9X -std=c9x C1X -std=c1x ANSI -ansi) This looks great. One question is what to do with things like gnu99. This is C99 plus GNU extensions. I ask because the GNU compiler separates this from regular C99, while other compilers like XL don't. If you run xlc -qlanglvl=c99, it supports inline assembly, but if you run gcc -std=c99, it does not. You have to run with std=gnu99. I *suspect* that most people will prefer gnu99 by default, as the lenient mode is the default for both gcc and xlc, but I could be conjecturing too far here. My suggestion would be to have an option like CMAKE_STRICT_C_DIALECT=TRUE that says to also turn off support for compiler-specific extensions if possible, e.g.: gcc:-std=c99 xlc:-qnoasm -qlanglvl=c99 and stick to the standard, but prefer the more lenient mode by default e.g.: gcc:-std=gnu99 xlc:-qlanglvl=c99 IMO, such a dialect strictness flag would be problematic due to the expectations the users may have and the undesired effects that may occur. E.g., does strict C99 mean that C89 constructs are rejected? For this, one needs to pass -pedantic-errors or the like to GCC, but I'd have objections to enable such a flag automatically since the user might prefer a non-pedantic behavior elsewhere. Further- more, what does strict C99 mean for compilers which don't fully support this standard, like MSVC as Hendrik has remarked in the meantime? Finally, the more flags one includes in the CMAKE_C_ DIALECT_C99 variable, the higher is the probability to cause contraries to the user's intention. Suppose one wants to have strict C99 *plus* inline assembly with XL C; one might initially configure the project with CFLAGS=-qasm cmake ... which makes the -qasm switch appear on the command line before the -qnoasm one enabled by CMAKE_C_DIALECT_C99 via the COMPILE_FLAGS property, e.g., so inline assembly is finally disabled, though requested explicitly. With __language_dialects(), one could edit the dialect flags in the cache taking -q[no]asm into account before the configuration starts. The approach with __language_dialects() is meant as a simple method to pass simple options to the compiler in order to express the need for a specific language dialect via a simple compiler-independent interface, but one should not aim at a more fine-grained control; regarding the different compilers with their countless command line options, this would be nearly impossible, even on the limited realm of language dialects. BTW, with GNU C, one would call __language_dialects() including GNU99 -std=gnu99 and the like, of course, since the user certainly expects that GNU compilers support GNU dialects. This turns out to be a simple and promising approach that - provides the developers with
Re: [CMake] Enabling C99 in CMake
On 06/27/2011 07:07 PM, Rolf Eike Beer wrote:
Michael Hertling wrote:
SET_SOURCE_FILES_PROPERTIES(${CMAKE_BINARY_DIR}/c89.c
PROPERTIES COMPILE_FLAGS ${CMAKE_C_DIALECT_C89})
SET_SOURCE_FILES_PROPERTIES(${CMAKE_BINARY_DIR}/c99.c
PROPERTIES COMPILE_FLAGS ${CMAKE_C_DIALECT_C99})
ADD_LIBRARY(c89 c89.c)
ADD_LIBRARY(c99 c99.c)
It issues the supported C dialects and the contents of the associated
dialect variables, and the c89.c and c99.c source files are compiled
with the correct flags. Of course, the CMAKE_C_DIALECT_DIALECT
variables can also be appended to the CMAKE_C_FLAGS[_CONFIG]
variables instead of the COMPILE_FLAGS source file property.
With a bit of thinking I would suggest a slightly different way. Don't add
specific compiler flags for that source file. Tell CMake that this sourcefile
uses
a specific language dialect:
SET_SOURCE_FILES_PROPERTIES(${CMAKE_BINARY_DIR}/c89.c
PROPERTIES LANGUAGE_DIALECT C89)
Then let CMake internally do the fiddling with the compile flags. This would
have a few benefits:
-if e.g. the language flags need to be passed first to the compiler CMake can
assure this
-colliding flags can be detected by the underlying implementation
-if we ever get support for e.g. 2 different C compilers things like the Sun
(was it Sun? Too lazy to look up) compilers can be supported as CMake would
just call the right compiler binary
-this can easily change in any direction later if someone decides the
underlying implementation needs a change
Well, basically all points target in the same direction, no? It seperates the
switch logic from the user and allow greater flexibility in the
implementation.
With the expense that probably some C++ code of CMake needs to be touched.
Eike
Currently, one can add a new compiler - a real one as well as a wrapper
script - without rebuilding CMake itself, and that's highly convenient.
Is it feasible to implement such a, say, flag management along with the
necessary knowlegde base, i.e. information about which flags to add/re-
move/modify/reorder, in pure CMake code? Do you intent to include flags
concerning dialect strictness? E.g., GCC with -std=c99 accepts legacy
C89 constructs, but doesn't recognize inline assembly introduced by the
asm keyword; other compilers might handle this differently. So, does
the C99 dialect property means strict C99, lenient C99 w.r.t. C89, C99
with common extensions etc., and will the decision be enforced? Pardon
for these critical questions, but I think they - and possibly others -
should be considered when contemplating a comprehensive management of
language dialect flags. The numerous compilers with their vast number
of flags - even just the dialect-related ones - make me believe that
this would be a nearly impossible undertaking. The approach with the
__language_dialects() function, in contrast, aims at a quite simple
mechanism doing simple things via a simple interface and is easy to
implement without narrowing the user's freedom more than necessary.
Additionally, it allows to query the basic dialect capabilities of
the compiler in charge and to edit the dialect flags in the cache
similar to the configuration flags CMAKE_LANG_FLAGS_CONFIG.
Regards,
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] ExternalProject, Install command
Sorry about possible double sending, I guess my first mail to this list
didn't come through.
I try to cross compile ppp as an external project. The install command is
INSTALL_COMMAND
make BINDIR=${EXTERNAL_PREFIX}/bin MANDIR=${EXTERNAL_PREFIX}/man
INSTALL='/usr/bin/install --strip-program=${STRIP_
PROGRAM}' install-progs
The install step fails with next error message
[ 0%] Performing install step for 'ppp'
make: unrecognized option
'--strip-program=/opt/crosstool/gcc-3.4.5-glibc-2.3.6/armv5b-softfloat-linux/bin/armv5b-softfloat-linux-strip''
Is there any way to set a white space separated value for the make inside
the ExternalProject or should I use a separate script? Running the build
step directly in a shell works fine.
Thanks advanced
-Veijo
___
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] CPACK NSIS Destination Directory
Hi,
I've been using CPack to generate NSIS installers. On my Windows 7 64-bit
development platform this works perfectly. When I started building the release
and generating the packages on our build server (also Windows 7 64-bit) things
aren't quite as smooth. The installer is generated fine, but the installer page
containing the Destination Directory fails to prefix the path with C:/Program
Files (x86), so instead of C:/Program Files(x86)/{{Project}} I'm presented with
/{{Project}}. Comparing the generated Project.nsi files between my development
environment and the production build environment, I notice that PROGRAMFILES
var is not used at all in the latter, but is in the former to construct
INSTALLDIR.
The only difference between my development environment and the production build
environment (as far as I can tell) is that my development is done on a physical
machine and the production machine is a VM. Might this have something to do
with PROGRAMFILES not being written into the nsis script? Does anyone have any
other suggestions about what might be causing this?
Thanks in advance,
Owen.
--
Scanned by iCritical.
___
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] Post-build copy
Hello everybody,
I build a static fortran library using CMake 2.8.0. Once the built is
done I would like to copy the library archive and its related Fortran
mod files stored in say, my_dir1, in another directory say, my_dir2.
Looking on the mailing list and on the web, I tried the following but
nothing happens:
ADD_CUSTOM_COMMAND(
TARGET crysfml
POST_BUILD
COMMAND ${CMAKE_COMMAND} -E make_directory my_dir2
COMMAND ${CMAKE_COMMAND} -E copy_directory my_dir1 my_dir2)
Am I doing something wrong ? Any idea ?
thanks a lot
See you
Eric
--
Eric Pellegrini
Calcul Scientifique
Institut Laue-Langevin
Grenoble, France
___
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] integrating separate packages in one superbuild eclipse project
Hello, we use CMake to build several libraries and applications for an embedded Linux target with a cross compile toolchain. Recently we separated this from one huge source tree to one standalone project for each library and application, each in its own Git repository. The classical approach for building and installing this is building the first library, install it to the target folder, then let dependent libs and applications use this target folder to search the include files and libs to link against. We could easily integrate this with ptxdist [1] which we use for building the software and finally get it on the target hardware. Using scripts for find_package() like FindFOO.cmake this works pretty well just like real world separate projects which depend on each other. However development inside this build environment is not so easy. It would be a lot more convenient to work with Eclipse. Now it's easy to setup an Eclipse project for each subproject, write code, jump around, commit something and so on, but when dependencies arouse, building gets difficult or even impossible, especially because a cross compiler is required. What we would like to have is an approach for creating some kind of superbuild project for Eclipse. For example for some application 'foo' which depends on 'libbar' and 'libbaz' we would like to have an Eclipse project with access to the sources of each of the three parts and a working build considering the dependencies. I guess this would mean Eclipse would build libbar and libbaz, install it to a common build target folder and build foo afterwards, in the best case with binaries in the build target folder which could be simply copied to the target hardware and run there for testing without further modifications? Is there a way to create such a meta build project or super build project with easy access to the source of all incorporated subprojects from within Eclipse? Thanks greets Alex [1] http://www.ptxdist.org/ -- »With the first link, the chain is forged. The first speech censured, the first thought forbidden, the first freedom denied, chains us all irrevocably.« (Jean-Luc Picard, quoting Judge Aaron Satie) *** GnuPG-FP: 02C8 A590 7FE5 CA5F 3601 D1D5 8FBA 7744 CC87 10D0 *** ___ 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] Strange behaviour with -D option
Hello everybody, there is a behaviour I do not understand when using cmake with -D option. In my project I defined a few CACHE variables. One of them is GUI to specify whether or not my project should be built with graphical library support. So in my main CMakeLists.txt I wrote something like: SET(GUI FALSE CACHE BOOL do the build in GUI mode) PROJECT(crysfml Fortran) ... When launching cmake with: cmake -G NMake Makefiles -D CMAKE_Fortran_COMPILER=ifort -D GUI=TRUE ..\..\. I always get the following message # GUI VALUE = TRUE -- Configuring done You have changed variables that require your cache to be deleted. Configure will be re-run and you may have to reset some variables. The following variables have changed: CMAKE_Fortran_COMPILER= ifort -- The Fortran compiler identification is Intel -- Check for working Fortran compiler: C:/Intel/Compiler/11.1/054/bin/ia32/ifort.exe -- Check for working Fortran compiler: C:/Intel/Compiler/11.1/054/bin/ia32/ifort.exe -- works -- Detecting Fortran compiler ABI info -- Detecting Fortran compiler ABI info - done -- Checking whether C:/Intel/Compiler/11.1/054/bin/ia32/ifort.exe supports Fortran 90 -- Checking whether C:/Intel/Compiler/11.1/054/bin/ia32/ifort.exe supports Fortran 90 -- yes GUI VALUE = FALSE -- Configuring done -- Generating done -- Build files have been written to: C:/Datas/Eclipse/workspace/crysfml/build/ifort_release_win # and the worse it that when deleting the cache and rebuilding it, the GUI variable is switched to FALSE as you can see in the two MESSAGE commands I put in my code (GUI VALUE =). Though, I would tend to think that the -D command should have the last word. There should be something I completely missed. thanks a lot see you Eric -- Eric Pellegrini Calcul Scientifique Institut Laue-Langevin Grenoble, France ___ 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] External_Project_Add() and custom build configurations ?
I have just started using some externally supplied cmake projects in my
cmake project. To do this I added these lines to my top level
CMakeLists.txt file:
include(ExternalProject)
ExternalProject_Add(external_proj
PREFIX${CMAKE_BINARY_DIR}/external_proj
SOURCE_DIR${CMAKE_SOURCE_DIR}/external/proj/dir
CMAKE_ARGS-DCMAKE_BUILD_TYPE:STRING=Release
-DMETAGS_DIR=${CMAKE_BINARY_DIR}/meta_install
INSTALL_COMMAND
)
And that worked very well. Inside Visual Studio when I build my project it
automatically runs the cmake configure step for the external projects and
builds them as well. The problem I have just discovered is when using a
build configuration other than the default ones. I can build Debug and
Release configurations fine. My project also has a DebugOptimised
configuration but the external projects don't. When I try to build my
project it fails to build the external projects. I used build_command() to
see what commands would be used to build each configuration and I can see
the cause of the problem:
Debug: VCExpress.exe myProj.sln /build Debug /project
external_proj
DebugOptimised: VCExpress.exe myProj.sln /build DebugOptimised /project
external_proj
Is there a way to tell cmake how to map my build configurations onto those
that an external project has ? In this case I would like to build the
external project as Debug when I am building my project as DebugOptimised.
--
Glenn
___
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] Download and Build external dependencies
Hi,
I'm currently trying to write a cmake script, which downloads some
source code and compile it during the configuration step. In my case
this I want to try it with BLAS from netlib.org because it represents
the problem in a good way ( and I need it for BLAS and similar
structured source code). That background is: If a necessary library
isn't found on the system, I will download the reference version and
compile it.
Therefore I wrote the following code:
# Download and Build reference BLAS
MESSAGE(STATUS -- BUILD BLAS)
file(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/build)
SET (BLAS_DIR ${CMAKE_BINARY_DIR}/build/BLAS)
MESSAGE(STATUS -- DOWNLOAD BLAS)
file(DOWNLOAD http://www.netlib.org/blas/blas.tgz
${CMAKE_BINARY_DIR}/build/blas.tgz SHOW_PROGRESS)
MESSAGE(STATUS -- EXTRACT BLAS)
execute_process(COMMAND tar xzf blas.tgz WORKING_DIRECTORY
${CMAKE_BINARY_DIR}/build/ )
MESSAGE(STATUS -- COMPILE BLAS: ${CMAKE_Fortran_COMPILER}
${CMAKE_FORTRAN_FLAGS} -c -O2 *.f in ${CMAKE_BINARY_DIR}/build/BLAS )
execute_process(COMMAND ${CMAKE_Fortran_COMPILER}
${CMAKE_FORTRAN_FLAGS} -c -O2 *.f WORKING_DIRECTORY
${CMAKE_BINARY_DIR}/build/BLAS/ )
execute_process(COMMAND ar cr libblas.a *.f WORKING_DIRECTORY
${CMAKE_BINARY_DIR}/build/BLAS/)
This works until the archive is extracted. The compile step seems to be
not executed. The ar step claims that there is not such file *.f
How can I get this running?
best regards, Martin
___
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] Download and Build external dependencies
On 07/01/2011 01:48 PM, Martin Köhler wrote:
Hi,
I'm currently trying to write a cmake script, which downloads some
source code and compile it during the configuration step. In my case
this I want to try it with BLAS from netlib.org because it represents
the problem in a good way ( and I need it for BLAS and similar
structured source code). That background is: If a necessary library
isn't found on the system, I will download the reference version and
compile it.
Therefore I wrote the following code:
# Download and Build reference BLAS
MESSAGE(STATUS -- BUILD BLAS)
file(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/build)
SET (BLAS_DIR ${CMAKE_BINARY_DIR}/build/BLAS)
MESSAGE(STATUS -- DOWNLOAD BLAS)
file(DOWNLOAD http://www.netlib.org/blas/blas.tgz
${CMAKE_BINARY_DIR}/build/blas.tgz SHOW_PROGRESS)
MESSAGE(STATUS -- EXTRACT BLAS)
execute_process(COMMAND tar xzf blas.tgz WORKING_DIRECTORY
${CMAKE_BINARY_DIR}/build/ )
MESSAGE(STATUS -- COMPILE BLAS: ${CMAKE_Fortran_COMPILER}
${CMAKE_FORTRAN_FLAGS} -c -O2 *.f in ${CMAKE_BINARY_DIR}/build/BLAS )
execute_process(COMMAND ${CMAKE_Fortran_COMPILER}
${CMAKE_FORTRAN_FLAGS} -c -O2 *.f WORKING_DIRECTORY
${CMAKE_BINARY_DIR}/build/BLAS/ )
execute_process(COMMAND ar cr libblas.a *.f WORKING_DIRECTORY
${CMAKE_BINARY_DIR}/build/BLAS/)
This works until the archive is extracted. The compile step seems to be
not executed. The ar step claims that there is not such file *.f
How can I get this running?
best regards, Martin
Don't reinvent the wheel, use the ExternalProject module that comes with
cmake-2.8 and newer.
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
Re: [CMake] Download and Build external dependencies
Looking at the following file may be helpful ..
SuperBuild/External_CLAPACK.cmakehttp://viewvc.slicer.org/viewvc.cgi/Slicer4/trunk/SuperBuild/External_CLAPACK.cmake?view=markup
There are also other examples in the
Superbuildhttp://viewvc.slicer.org/viewvc.cgi/Slicer4/trunk/SuperBuild/folder.
Hth
Jc
On Fri, Jul 1, 2011 at 8:10 AM, Michael Wild them...@gmail.com wrote:
On 07/01/2011 01:48 PM, Martin Köhler wrote:
Hi,
I'm currently trying to write a cmake script, which downloads some
source code and compile it during the configuration step. In my case
this I want to try it with BLAS from netlib.org because it represents
the problem in a good way ( and I need it for BLAS and similar
structured source code). That background is: If a necessary library
isn't found on the system, I will download the reference version and
compile it.
Therefore I wrote the following code:
# Download and Build reference BLAS
MESSAGE(STATUS -- BUILD BLAS)
file(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/build)
SET (BLAS_DIR ${CMAKE_BINARY_DIR}/build/BLAS)
MESSAGE(STATUS -- DOWNLOAD BLAS)
file(DOWNLOAD http://www.netlib.org/blas/blas.tgz
${CMAKE_BINARY_DIR}/build/blas.tgz SHOW_PROGRESS)
MESSAGE(STATUS -- EXTRACT BLAS)
execute_process(COMMAND tar xzf blas.tgz WORKING_DIRECTORY
${CMAKE_BINARY_DIR}/build/ )
MESSAGE(STATUS -- COMPILE BLAS: ${CMAKE_Fortran_COMPILER}
${CMAKE_FORTRAN_FLAGS} -c -O2 *.f in ${CMAKE_BINARY_DIR}/build/BLAS )
execute_process(COMMAND ${CMAKE_Fortran_COMPILER}
${CMAKE_FORTRAN_FLAGS} -c -O2 *.f WORKING_DIRECTORY
${CMAKE_BINARY_DIR}/build/BLAS/ )
execute_process(COMMAND ar cr libblas.a *.f WORKING_DIRECTORY
${CMAKE_BINARY_DIR}/build/BLAS/)
This works until the archive is extracted. The compile step seems to be
not executed. The ar step claims that there is not such file *.f
How can I get this running?
best regards, Martin
Don't reinvent the wheel, use the ExternalProject module that comes with
cmake-2.8 and newer.
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
--
+1 919 869 8849
___
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] install( TARGETS module ...)
Dear all, I am trying to change the default behavior of cmake which installs MODULE to the LIBRARY destination. For example: ... add_library(test MODULE test.c) install(TARGETS test RUNTIME DESTINATION bin LIBRARY DESTINATION lib ARCHIVE DESTINATION lib/static ) ... Will install test.dll to lib, while a SHARED target would have been installed to bin. Is there an easy work around ? I cannot change MODULE to SHARED in add_library(). I would also like to keep installation to lib, in case of UNIX system (basically I want the SHARED behavior for install() but with MODULE). Thanks for suggestion, -- Mathieu ___ 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] CPack -- adding license to files
Hi all, I was wondering if there is an easy/automated way that I can get CMake or CPack to add a license to every source file prior to distribution of the source. Of course, I mean that I would provide the wording of the license and all it does is copy this license to the top of each source file in a way that is specific to the language (ideally). i.e., using // for C++ source files. It would be nice if it could also update dates too, but that's more of a wishlist. (i.e., changing Copyright 2011 to Copyright 2011-2012) Thank you! Ray ___ 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] CPack -- adding license to files
Sounds like more of a job for perl, python or ruby to me. On Fri, Jul 1, 2011 at 12:17 PM, Raymond Wan r@aist.go.jp wrote: Hi all, I was wondering if there is an easy/automated way that I can get CMake or CPack to add a license to every source file prior to distribution of the source. Of course, I mean that I would provide the wording of the license and all it does is copy this license to the top of each source file in a way that is specific to the language (ideally). i.e., using // for C++ source files. It would be nice if it could also update dates too, but that's more of a wishlist. (i.e., changing Copyright 2011 to Copyright 2011-2012) Thank you! Ray ___ 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] External_Project_Add() and custom build configurations ?
On Fri, Jul 1, 2011 at 7:23 AM, Glenn Coombs glenn.coo...@gmail.com wrote:
I have just started using some externally supplied cmake projects in my
cmake project. To do this I added these lines to my top level
CMakeLists.txt file:
include(ExternalProject)
ExternalProject_Add(external_proj
PREFIX${CMAKE_BINARY_DIR}/external_proj
SOURCE_DIR${CMAKE_SOURCE_DIR}/external/proj/dir
CMAKE_ARGS-DCMAKE_BUILD_TYPE:STRING=Release
-DMETAGS_DIR=${CMAKE_BINARY_DIR}/meta_install
INSTALL_COMMAND
)
And that worked very well. Inside Visual Studio when I build my project it
automatically runs the cmake configure step for the external projects and
builds them as well. The problem I have just discovered is when using a
build configuration other than the default ones. I can build Debug and
Release configurations fine. My project also has a DebugOptimised
configuration but the external projects don't. When I try to build my
project it fails to build the external projects. I used build_command() to
see what commands would be used to build each configuration and I can see
the cause of the problem:
Debug: VCExpress.exe myProj.sln /build Debug /project
external_proj
DebugOptimised: VCExpress.exe myProj.sln /build DebugOptimised /project
external_proj
Is there a way to tell cmake how to map my build configurations onto those
that an external project has ? In this case I would like to build the
external project as Debug when I am building my project as DebugOptimised.
--
Glenn
___
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
With Visual Studio builds, external projects get built (by default) with the
same configuration as the outer project. If you want a different
configuration built, then you will have to customize the BUILD_COMMAND. You
can look in the source for ExternalProject.cmake to see how the default
BUILD_COMMAND is constructed and go from there.
HTH,
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] CMake Wiki spammed
Those users have been blocked from our wiki. Let us know if you see any more suspicious activity. Thanks, David On Thu, Jun 30, 2011 at 7:30 PM, David Cole david.c...@kitware.com wrote: I have forwarded this to our IT team... Hopefully it's not too hard to recover from for them. Thanks, David On Thu, Jun 30, 2011 at 7:24 PM, John Drescher dresche...@gmail.comwrote: On Thu, Jun 30, 2011 at 6:27 PM, Moreland, Kenneth kmo...@sandia.gov wrote: It looks like the CMake Wiki recently got spammed. I see several links were recently added that do not belong (head lice treatment?). Even more annoying, it looks like the spammer removed some links that do belong there. It's a mess. I was trying to back out of this but there are multiple SPAM edits in between a few good edits. Ahmed appears to have done most of the spamming. John ___ 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] Install targets
Hi, We have a project that has a main executable and dozens of utility executables that may or may not be needed. We can add an executable for each util with EXCLUDE_FROM_ALL defined so just typing make only does the main code and something like 'make grid' compiles the grid generator. But, how can we install these things? I see from the documentation that if EXCLUDE_FROM_ALL is set to true, the behavior is undefined. More generally, is there a way to set 'make install' to only install things that have been built (rather than the current behavior which is to build the default target if it's not built)? A work around would be to create custom install targets that use the cmake copy command to manually move the utility executable to the install directory, but it would be nice if 'make install' installed all targets built without building unbuilt ones... Thanks, Tim ___ 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-commits] CMake branch, next, updated. v2.8.4-1846-g89ed078
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via 89ed078226e89a49ebc86c91165d16b1d0e9df66 (commit) via 5a022c3339b8d120de860fc7735b534bf3400a57 (commit) from 2cab5e146886bbaf7f1d31ddc5b02b1ae0b604a3 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=89ed078226e89a49ebc86c91165d16b1d0e9df66 commit 89ed078226e89a49ebc86c91165d16b1d0e9df66 Merge: 2cab5e1 5a022c3 Author: Brad King brad.k...@kitware.com AuthorDate: Fri Jul 1 08:51:19 2011 -0400 Commit: Brad King brad.k...@kitware.com CommitDate: Fri Jul 1 08:51:19 2011 -0400 Merge branch 'master' into next --- Summary of changes: Source/kwsys/kwsysDateStamp.cmake |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.4-611-gfe9ac70
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via fe9ac70076c6c7a1c4bf4c841cb3d99e8971 (commit) from 5a022c3339b8d120de860fc7735b534bf3400a57 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fe9ac70076c6c7a1c4bf4c841cb3d99e8971 commit fe9ac70076c6c7a1c4bf4c841cb3d99e8971 Author: KWSys Robot kwro...@kitware.com AuthorDate: Sat Jul 2 00:01:05 2011 -0400 Commit: KWSys Robot kwro...@kitware.com CommitDate: Sat Jul 2 00:13:02 2011 -0400 KWSys Nightly Date Stamp diff --git a/Source/kwsys/kwsysDateStamp.cmake b/Source/kwsys/kwsysDateStamp.cmake index d0fb705..7ec4e61 100644 --- a/Source/kwsys/kwsysDateStamp.cmake +++ b/Source/kwsys/kwsysDateStamp.cmake @@ -18,4 +18,4 @@ SET(KWSYS_DATE_STAMP_YEAR 2011) SET(KWSYS_DATE_STAMP_MONTH 07) # KWSys version date day component. Format is DD. -SET(KWSYS_DATE_STAMP_DAY 01) +SET(KWSYS_DATE_STAMP_DAY 02) --- Summary of changes: Source/kwsys/kwsysDateStamp.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
