Re: [CMake] Better BlueGene/P and cross-compile support for CMake
Hi Alex,
On Thu, 2010-06-24 at 22:52 +0200, Alexander Neundorf wrote:
On Thursday 24 June 2010, Marcel Loose wrote:
Oops! Forgot to CC to the list.
Hi Tod,
I'll try to answer some of your questions below inline (I've snipped
off
parts of your mail). We're also using a BlueGeneP, but not for so
many
packages/executables as you probably do.
On Wed, 2010-06-23 at 01:02 -0700, Todd Gamblin wrote:
Hi,
-- 8 - 8 - 8 - 8 - 8 - 8 - 8 - 8
--
I was able to build with either if I just manually specified the
compilers and linker like this:
env CC=gcc C++=g++ LD=ld ./bootstrap --prefix=${CMAKE_HOME}
env CC=xlc C++=xlC LD=xlC ./bootstrap --prefix=${CMAKE_HOME}
That is probably the safest way to do it, anyways. You then have
full
control over which compiler is used to build your stuff.
But It would've been nice if I didn't have to do all that. Is PPC
Linux not used many other places anymore? I guess this is a
sles10/ppc64 environment, so maybe that is throwing the script
off.
2. The FindMPI module's library search breaks because the the
cross-compiler name on BlueGene/P contains -l. Specifically, the
GNU
compute node compilers on BlueGene/P are named like this:
powerpc-bgp-linux-g++
And the FindMPI module claims that it can't find the '-inux-g++'
library, or something similar. I was able to fix this by
modifying
FindMPI's search to look for -l only when it's followed by a
space.
This is a little worrisome because I think that is a standard gnu
naming convention, so other platforms with compilers named
blah-linux
are going to have the same bug.
That is a known bug. I've filed it in the bug tracker
http://www.vtk.org/Bug/view.php?id=9093. I've also uploaded a patch
(take the second one), that fixes that problem.
In the bug report you say This patch is NOT heavily tested!
Is this still true ?
Alex
By heavily tested, I meant tested by several people on multiple
platforms. It works for me. I think the patch is pretty straightforward
and harmless, but I've been bitten before in the past by supposedly
harmless trivial patches that did have side-effects on some (obscure?)
system. Maybe, my wording was too cautious.
Best regards,
Marcel Loose.
___
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] Mixed Fortran and C++ projects in Visual Studio with Intel Fortran Compiler
Hi! We have a problem on Windows with Visual Studio projects and the Intel Fortran 11.1 compiler. We have a project the contains Fortran sources and links a static C++ library. So in Visual Studio this project is a Fortran project. With update 38 of the Fortran compiler this was working without any problems because the normal Visual Studio linker (link.exe) was used. Now we want to use update 65 of the Fortran compiler. This update enforces Visual Studio to use the Intel Fortran xilink for linking Fortran projects. But with this linker it isn't possible to link the static C++ library to the Fortran project. It would be possible to change the library structure, so that the Fortran project only contains the Fortran sources. But we try do avoid this. We also tried to set the LINKER_LANGUAGE target property to C++, but this doesn't change anything. Still the same Visual Studio projects are generated. So is there any way in cmake to enforce Visual Studio to use link.exe instead of xilink.exe? Bye Marcus ___ 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] Custom memory checking result processing
Dear all, I am using valgrind to debug a framework which depends on several other underlying frameworks to function properly. As a result my memory checking turns up thousands of errors. I only want to see errors that arise from my framework. This is figured can be done by simply looking for a few regular expressions in the stack trace. Right now i am planning on creating a custom perl script which i will use as the memchecker instead of valgrind and send its output to CDash. Suppression files don't seem feasible as they don't have any sort of RegEx support and i have too many errors to list in a file creating ridiculously large logs and suppression files. I was wondering is there any better way to tackle this problem ? Regards Johny ___ 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] Build rule for specific file extension
Hi, is there a way to tell CMake how to compile files based on their extension? For example, here's a make rule to build an object file from a *.lst file: %.o : %.lst echo #include \irx_imports.h\ build-imports.c cat $ build-imports.c $(IOP_CC) $(IOP_CFLAGS) build-imports.c -o $@ -rm -f build-imports.c How can I convert this to CMake? I considered using add_custom_target, but I don't know how to apply it to all files with the same extension. -Mathias ___ 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] Custom memory checking result processing
I can't really think of a better way to tackle the problem... But I will make this one observation: If these underlying frameworks you depend on produce *thousands* of valgrind errors, do you really want to be depending on them? (Serious question, not trying to be flippant... It would make me very nervous to depend on a framework that has more than a handful of valgrind issues: and each issue would have to be something that I was convinced did not have a high likelihood of occurring in real world usage scenarios.) Just my opinion, David On Fri, Jun 25, 2010 at 7:18 AM, Johny Jose johny.j...@cern.ch wrote: Dear all, I am using valgrind to debug a framework which depends on several other underlying frameworks to function properly. As a result my memory checking turns up thousands of errors. I only want to see errors that arise from my framework. This is figured can be done by simply looking for a few regular expressions in the stack trace. Right now i am planning on creating a custom perl script which i will use as the memchecker instead of valgrind and send its output to CDash. Suppression files don't seem feasible as they don't have any sort of RegEx support and i have too many errors to list in a file creating ridiculously large logs and suppression files. I was wondering is there any better way to tackle this problem ? Regards Johny ___ 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] customize cpack windows installer
Den 23-06-2010 23:39, Alexandre Gramfort skrev: I'm deploying a cmake project on windows and I have a few questions concerning the installer generated by cpack using NSIS - is it possible to remove the mention create desktop icon since the installer contains only command line tools? - is it possible to provide an installer that works even if the user does not have admin rights? - is it possible to add to the folder in the start menu a link that points to the web site of the project? Hi Alexandre, I recently started using CPack for the MariaDB installer, and it's been a kind-of bumpy ride so far. First of all, it's incredibly easy to build a simple installer with CPack and NSIS. But as soon as you step beyond the glorified zip file structure, it starts getting really hairy. I can't answer any of your questions, because I haven't tried to do those things. But I can tell you what I do when I try to find solutions to problems: 1) Search the net 2) Ask questions on the mailing list. One question per mail only! This looks like it gives the best answers, when answers are given. 3) Read the file ...\CMake 2.8\share\cmake-2.8\Modules\NSIS.template.in to try and figure out what happens and what you can or can't do. Be aware that NSIS is actually in some ways quite limited in what it can do. And the CPack template doesn't always provide the freedom I'd like to have. For example, just adding new functions or macros seem difficult (i might be wrong about this, though). An alternative to NSIS is to use CPack with the WiX patch. This can pretty much do everything you'd expect an installer system to do. But it means depending on an external CMake patch plus you have to write a very complicated .xsl file for it to do anything useful. Another thing: If you find the answers to your questions, please answer your own mail here on the list. Google results from answers on this list is certainly one of the more useful resources on the net. Bo Thorsen. Monty Program AB. -- MariaDB: MySQL replacement Community developed. Feature enhanced. Backward compatible. ___ 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] Data dir
Just to follow my own advice and give the answer to the question I sent
here.
The basic problem is this: Can you add a file to the installer that
isn't uninstalled?
Answer: No, this is impossible. Anything short of patching the CMake
sourcecode is going to fail. Not even copying the NSIS template to the
local directory and modify it is going to work.
The workaround I use now installs my datafiles to a clean directory,
which isn't used by MariaDB on runtime. It then checks if there are
already database files in the target dir. If they are there, it gives a
messagebox saying it's reusing the database files. If no files are there
(or at least not the one file I check), the clean files are copied into
position.
On uninstall, I just put up a messagebox saying the database files are
not deleted. I plan to investigate if it's possible to add pages to the
uninstaller and ask the user if he/she wants to delete the files or not.
But in the meantime this isn't an unreasonable workaround.
To do this, I have removed my data component, so the clean database
files are now in the unspecified group, which means the user can't avoid
them. And then I added these lines to my CMakeLists.txt:
# Handle the database files
FILE(GLOB datafiles ${CMAKE_CURRENT_SOURCE_DIR}/win/data/mysql/*)
INSTALL(FILES ${datafiles} DESTINATION data/clean/mysql)
INSTALL(FILES win/data/maria_log.0001 win/data/maria_log_control
DESTINATION data/clean)
INSTALL(DIRECTORY win/data/test DESTINATION data/clean)
SET(CPACK_NSIS_EXTRA_INSTALL_COMMANDS ${CPACK_NSIS_EXTRA_INSTALL_COMMANDS}
IfFileExists '$INSTDIRdatamysqldb.frm' 0 CopyDatabaseFiles
MessageBox MB_OK 'There are already database files present in the
data directory. Clean database files are not written to the directory'
GoTo EndCopyDatabaseFiles
CopyDatabaseFiles:
CopyFiles '$INSTDIRdataclean*' '$INSTDIRdata'
EndCopyDatabaseFiles:)
SET(CPACK_NSIS_EXTRA_UNINSTALL_COMMANDS
${CPACK_NSIS_EXTRA_UNINSTALL_COMMANDS}
MessageBox MB_OK 'This will not delete the database files in
$INSTDIRdata')
Another solution I'm considering is to write a CMake patch that can do
this in a prettier way, but that's going to be a while from now, if ever.
Bo.
Den 09-06-2010 14:48, Bo Thorsen skrev:
Den 09-06-2010 14:25, Yegor Yefremov skrev:
I am working on a CPack/NSIS based installer for MariaDB. The early
parts were really easy to do, but now it becomes more complicated.
First problem: I have a set of files with the bootstrap MySQL/MariaDB
database files. Some users might not want to install these, if they are
installing to a set of database files that are already there.
Have you already looked at this article:
http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack
Yes, I already implemented this, and it works very well. However, I
think it's too little. I guess I'm not really certain how the installer
should actually work, which is one of the reasons I'm fishing for an
answer.
It think anything less than a page where the user has to answer this
manually will be too subtle for the data dir. I'm happy with this on
stuff like installing header files for installation.
The reason I'm worried is if a user had a previous installation with the
datafiles in there, and installs in the same directory, it might be easy
to overwrite the files.
I think a separate page with three options to choose from
- install new files
- use existing files in the installation directory
- use data files in a separate location
Or something like this. If someone already did something this advanced
with CPack, it would be great to hear about it. I suspect that I'll have
to work directly in the nsis module file to implement this.
Anyway, components doesn't answer the uninstall problem.
Bo Thorsen.
Monty Program AB.
Bo Thorsen.
Monty Program AB.
--
MariaDB: MySQL replacement
Community developed. Feature enhanced. Backward compatible.
___
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] Various problems deploying a python module
On 06/25/2010 03:42 PM, David Cole wrote: I would have thought it was a git commit hash... but I cannot find it at: http://cmake.org/gitweb?p=cmake.git;a=summary Perhaps it's in another git repo? No, it's in your first-order repository: git clone git://cmake.org/cmake.git cd cmake git show 8d87d12 Regards, Michael On Fri, Jun 25, 2010 at 9:17 AM, Janosch Peters j...@binford3000.de wrote: On 2010-06-21 07:01:36 +0200, Michael Hertling said: 8d87d12 What's that? Leet speak? -- Janosch ___ 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] Various problems deploying a python module
On Fri, Jun 25, 2010 at 9:42 AM, David Cole david.c...@kitware.com wrote: I would have thought it was a git commit hash... but I cannot find it at: http://cmake.org/gitweb?p=cmake.git;a=summary Perhaps it's in another git repo? Oops. Thanks Michael, for pointing us to http://cmake.org/gitweb?p=cmake.git;a=commit;h=8d87d12 Apparently, I don't know how to use the gitweb search feature correctly. Searching on commit searches the text of the commit... not for its identifier. On Fri, Jun 25, 2010 at 9:17 AM, Janosch Peters j...@binford3000.de wrote: On 2010-06-21 07:01:36 +0200, Michael Hertling said: 8d87d12 What's that? Leet speak? -- Janosch ___ 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] CMake Xcode SCC
Same for all project configurations like environment variables and others... I'm also looking for a solution to that problem. I guess the solution would be to make these settings available as CMake variables that are remembered by the CMake cache. So far I haven't found a way to do that, if it is possible. s. On Thu, Jun 24, 2010 at 11:03 PM, Glenn Hughes ghughes02...@gmail.comwrote: Hi all, I'm using Xcode 3.2.2 and Perforce for my Source Code Control. Whenever I rebuild the Xcode project with cmake, Xcode loses its connection to the source code server and I have to reset it manually. Does anyone have a solution for this? Thanks in advance 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 ___ 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] find_file and following links on windows
I have created a simple CMakeLists.txt file:
FIND_FILE(tmp_h tmp.h PATHS /cygwin/home/cary/tmp/tmp1)
MESSAGE(tmp_h = ${tmp_h}
and inside of tmp1 I have put the file tmp.h.
This works fine. The output contains
tmp_h = /cygwin/home/cary/tmp/tmp1/tmp.h
Then I create a lnk and rename it
In tmp:
mkshortcut tmp1
mv tmp1.lnk tmp2.lnk
and try
FIND_FILE(tmp_h tmp.h PATHS /cygwin/home/cary/tmp/tmp2)
MESSAGE(tmp_h = ${tmp_h}
and it fails.
tmp_h = tmp_h-NOTFOUND
Is this expected behavior? Am I doing something wrong?
ThxJohn Cary
___
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] Various problems deploying a python module
On 2010-06-25 15:45:37 +0200, Michael Hertling said: On 06/25/2010 03:17 PM, Janosch Peters wrote: On 2010-06-21 07:01:36 +0200, Michael Hertling said: 8d87d12 What's that? Leet speak? No, these are the first seven and sufficiently unambiguous digits of the SHA-1 sum of the commit in CMake's Git repository that removes the framework related lines from FindPythonLibs.cmake Ok. But the python dilemma still remains: 1. FindPythonInterp and FindPythonLibs might still produce inconsistent results (e.g. libs and interpreter of different python versions) 2. AFAIK you cannot specify a specific python version you which to include/link I think someone on the list suggested to merge both modules into one, which would help making the results consistent. Is this (or any other solution) on your todo list? -- Janosch ___ 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] Custom memory checking result processing
For the cmake valgrind dashboard, we use the script seen here:
http://www.cdash.org/CDash/viewNotes.php?buildid=647028
If you look at it, you will see that we list a bunch of tools that produce
valgrind output that we are not interested in having show up on the CMake
dashboard.
(For example, /usr/bin/gcc and /usr/bin/c++ are in the list...)
Then, we pass that to valgrind with the
--trace-children-skip=${valgrind_skip} command line flag.
Here's the catch: that's a custom build of valgrind that we have on that
machine that understands this flag. I think Bill Hoffman developed the patch
for that behavior and tried to submit it up to valgrind upstream, but there
was much discussion and no action, if I recall correctly.
Maybe Bill could chime in, or you could take up the question on valgrind's
mailing list?
HTH,
David
On Fri, Jun 25, 2010 at 9:44 AM, Johny Jose johny.j...@cern.ch wrote:
The frameworks in question are a necessary evil, we cannot do without
them, time and habit will not allow us to work with anything else i guess.
Well i guess i will have to try it out and see what comes of it, will let u
know how successful it is.
Regards,
Johny
-Original Message-
From: Marcel Loose [mailto:lo...@astron.nl]
Sent: Fri 6/25/2010 2:30 PM
To: david.c...@kitware.com
Cc: Johny Jose; cmake@cmake.org
Subject: Re: [CMake] Custom memory checking result processing
Well, I sort of ran into exactly the same problem that Johny describes.
I devoted two mails on this issue to the CMake list --
http://www.mail-archive.com/cmake@cmake.org/msg26858.html
http://www.mail-archive.com/cmake@cmake.org/msg29155.html -- but got no
response on either of them.
In my case 'bash' is producing quite some noise; wouldn't want to call
'bash' flaky, though. But even if that weren't the case: you don't want
to memory check your framework every time you run a test, only the
program under test.
There must be a better way to solve this, right?
Best regards,
Marcel Loose.
On Fri, 2010-06-25 at 07:47 -0400, David Cole wrote:
I can't really think of a better way to tackle the problem...
But I will make this one observation:
If these underlying frameworks you depend on produce *thousands* of
valgrind errors, do you really want to be depending on them?
(Serious question, not trying to be flippant... It would make me very
nervous to depend on a framework that has more than a handful of
valgrind issues: and each issue would have to be something that I was
convinced did not have a high likelihood of occurring in real world
usage scenarios.)
Just my opinion,
David
On Fri, Jun 25, 2010 at 7:18 AM, Johny Jose johny.j...@cern.ch
wrote:
Dear all,
I am using valgrind to debug a framework which depends on
several other underlying frameworks to function properly. As a
result my memory checking turns up thousands of errors. I only
want to see errors that arise from my framework. This is
figured can be done by simply looking for a few regular
expressions in the stack trace. Right now i am planning on
creating a custom perl script which i will use as the
memchecker instead of valgrind and send its output to CDash.
Suppression files don't seem feasible as they don't have any
sort of RegEx support and i have too many errors to list in a
file creating ridiculously large logs and suppression files. I
was wondering is there any better way to tackle this problem ?
Regards
Johny
___
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
___
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] Custom memory checking result processing
On 6/25/2010 7:47 AM, David Cole wrote:
I can't really think of a better way to tackle the problem...
But I will make this one observation:
If these underlying frameworks you depend on produce *thousands* of
valgrind errors, do you really want to be depending on them?
(Serious question, not trying to be flippant... It would make me very
nervous to depend on a framework that has more than a handful of
valgrind issues: and each issue would have to be something that I was
convinced did not have a high likelihood of occurring in real world
usage scenarios.)
So, lots of things that you have to use like libX11 have tons and tons
of valgrind stuff in them. Some are not real, some are, but you still
have to use those libraries as they are. What you do is create a
valgrind suppression file. What I usally do is run valgrind with
--gen-suppressions=all. This makes valgrind spit out the exact text to
put in the suppression file. This output will show up on the dashboard.
You use that to create a suppression file that you pass to valgrind.
Then you set this in the cache:
MEMORYCHECK_SUPPRESSIONS_FILE:FILEPATH=${CTEST_MEMORYCHECK_SUPPRESSIONS_FILE}
CTEst will then use that as a suppression file. You keep adding to the
suppression file until you have it like you want. Many times it is the
same thing over and over, so a few suppressions go a long way.
-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
Re: [CMake] Custom memory checking result processing
On 6/25/2010 10:16 AM, David Cole wrote:
For the cmake valgrind dashboard, we use the script seen here:
http://www.cdash.org/CDash/viewNotes.php?buildid=647028
If you look at it, you will see that we list a bunch of tools that
produce valgrind output that we are not interested in having show up on
the CMake dashboard.
(For example, /usr/bin/gcc and /usr/bin/c++ are in the list...)
Then, we pass that to valgrind with the
--trace-children-skip=${valgrind_skip} command line flag.
Here's the catch: that's a custom build of valgrind that we have on that
machine that understands this flag. I think Bill Hoffman developed the
patch for that behavior and tried to submit it up to valgrind upstream,
but there was much discussion and no action, if I recall correctly.
The patch has been accepted and is in valgrind. It is a slight
different format but does the same thing. So, an SVN valgrind will have
the new flag.The other thing to note is that this stops all
processing after that. So, for example since make will call cmake, we
allow make to be valgrind processed, and just add the suppression stuff
I mentioned in my other email.
Maybe Bill could chime in, or you could take up the question on
valgrind's mailing list?
No need to go on the valgrind list, should be there now. I have not
tested and really do need to upgrade our valgrind to try the official
version of this feature...
-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
Re: [CMake] Various problems deploying a python module
On Jun 25, 2010, at 9:11 AM, Janosch Peters wrote: On 2010-06-25 15:45:37 +0200, Michael Hertling said: On 06/25/2010 03:17 PM, Janosch Peters wrote: On 2010-06-21 07:01:36 +0200, Michael Hertling said: 8d87d12 What's that? Leet speak? No, these are the first seven and sufficiently unambiguous digits of the SHA-1 sum of the commit in CMake's Git repository that removes the framework related lines from FindPythonLibs.cmake Ok. But the python dilemma still remains: 1. FindPythonInterp and FindPythonLibs might still produce inconsistent results (e.g. libs and interpreter of different python versions) 2. AFAIK you cannot specify a specific python version you which to include/link I think someone on the list suggested to merge both modules into one, which would help making the results consistent. Is this (or any other solution) on your todo list? I suggested the merge, and proposed to add a function to check for the existence of python modules: http://www.cmake.org/pipermail/cmake/2010-June/037468.html On my OS X machine, the headers and libs for different python versions also exist in the more common UNIX places (/usr/include/python2.x, /usr/lib/libpython2.x.dylib, /usr/lib/python2.x/config/libpython2.x.a, and corresponding MacPorts locations). I don’t know of any way you can specify a specific version of a framework, so (at least for python) it seems easier to drop framework support altogether and just use the UNIX paths. -- Mark ___ 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] Custom memory checking result processing
Thanks for the suggestions, but i already went down these paths. The problem is
my logs in xml format on an average go above 100 MB of output, with
gen-suppressions i get 300MB output files and the suppressions file generated
out of these is again way too big for my liking.
If only valgrind had more features in terms of expressing suppression rules
like some sort of pattern matcher which would suppress all errors except the
matching ones it would have been easier, because the errors i want to look at
match a contain a particular pattern. Right now the only workaround is manually
parsing the xml log file and selecting the errors i want to see. I used to have
problems viewing these results too on CDash because of the huge file sizes.
Using a generated suppression files even if i optimized it with wildcards is
not feasible since i have no way of knowing which errors i don't need but i do
know which errors i do need. It would be a really great feature to add to
valgrind.
Regards,
Johny
-Original Message-
From: cmake-boun...@cmake.org on behalf of Bill Hoffman
Sent: Fri 6/25/2010 4:17 PM
To: cmake@cmake.org
Subject: Re: [CMake] Custom memory checking result processing
On 6/25/2010 7:47 AM, David Cole wrote:
I can't really think of a better way to tackle the problem...
But I will make this one observation:
If these underlying frameworks you depend on produce *thousands* of
valgrind errors, do you really want to be depending on them?
(Serious question, not trying to be flippant... It would make me very
nervous to depend on a framework that has more than a handful of
valgrind issues: and each issue would have to be something that I was
convinced did not have a high likelihood of occurring in real world
usage scenarios.)
So, lots of things that you have to use like libX11 have tons and tons
of valgrind stuff in them. Some are not real, some are, but you still
have to use those libraries as they are. What you do is create a
valgrind suppression file. What I usally do is run valgrind with
--gen-suppressions=all. This makes valgrind spit out the exact text to
put in the suppression file. This output will show up on the dashboard.
You use that to create a suppression file that you pass to valgrind.
Then you set this in the cache:
MEMORYCHECK_SUPPRESSIONS_FILE:FILEPATH=${CTEST_MEMORYCHECK_SUPPRESSIONS_FILE}
CTEst will then use that as a suppression file. You keep adding to the
suppression file until you have it like you want. Many times it is the
same thing over and over, so a few suppressions go a long way.
-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
Re: [CMake] Various problems deploying a python module
On 25. Jun, 2010, at 16:32 , Mark Moll wrote: On Jun 25, 2010, at 9:11 AM, Janosch Peters wrote: On 2010-06-25 15:45:37 +0200, Michael Hertling said: On 06/25/2010 03:17 PM, Janosch Peters wrote: On 2010-06-21 07:01:36 +0200, Michael Hertling said: 8d87d12 What's that? Leet speak? No, these are the first seven and sufficiently unambiguous digits of the SHA-1 sum of the commit in CMake's Git repository that removes the framework related lines from FindPythonLibs.cmake Ok. But the python dilemma still remains: 1. FindPythonInterp and FindPythonLibs might still produce inconsistent results (e.g. libs and interpreter of different python versions) 2. AFAIK you cannot specify a specific python version you which to include/link I think someone on the list suggested to merge both modules into one, which would help making the results consistent. Is this (or any other solution) on your todo list? I suggested the merge, and proposed to add a function to check for the existence of python modules: http://www.cmake.org/pipermail/cmake/2010-June/037468.html On my OS X machine, the headers and libs for different python versions also exist in the more common UNIX places (/usr/include/python2.x, /usr/lib/libpython2.x.dylib, /usr/lib/python2.x/config/libpython2.x.a, and corresponding MacPorts locations). I don’t know of any way you can specify a specific version of a framework, so (at least for python) it seems easier to drop framework support altogether and just use the UNIX paths. -- Mark To chime in... For one, the libraries in /usr/lib are symlinked to the framework: $ readlink /usr/lib/libpython2.6.dylib ../../System/Library/Frameworks/Python.framework/Versions/2.6/Python However, I think it's really difficult to guarantee consistency. If the code to be compiled contains stuff like the following #ifdef __APPLE__ #include Python/Python.h #else #include Python.h #endif the compiler will compile against the latest framework installation it finds on the search path (probably /System/Library/Frameworks/Python.framework), but for linking whatever CMake (or the user by modifying the cache) chooses to pick will be used, be that the framework installation or some library-installation (Fink, MacPorts, /usr/lib, user-installed, ...). 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] Various problems deploying a python module
On 2010-06-25 16:32:38 +0200, Mark Moll said: On Jun 25, 2010, at 9:11 AM, Janosch Peters wrote: Ok. But the python dilemma still remains: 1. FindPythonInterp and FindPythonLibs might still produce inconsistent results (e.g. libs and interpreter of different python versions) 2. AFAIK you cannot specify a specific python version you which to include/link I think someone on the list suggested to merge both modules into one, which would help making the results consistent. Is this (or any other solution) on your todo list? I suggested the merge, and proposed to add a function to check for the existence of python modules: http://www.cmake.org/pipermail/cmake/2010-June/037468.html On my OS X machine, the headers and libs for different python versions also exist in the more common UNIX places (/usr/include/python2.x, /usr/lib/libpython2.x.dylib, /usr/lib/python2.x/config/libpython2.x.a, and corresponding MacPorts locations). I don’t know of any way you can specify a specific version of a framework, so (at least for python) it seems easier to drop framework support altogether and just use the UNIX paths. I thought -framework 'path/to/the/framework/you/want/to/use' would work, but I havent tested it. Anyway, your find_package script looks very promising. I'll give it a try. What do you mean by UNIX-biased? Does it work only on Unix/Linux/OS X? Would be great if that script would be considered for one of the next releases. -- Janosch ___ 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] Various problems deploying a python module
On 2010-06-25 16:58:47 +0200, Michael Wild said: However, I think it's really difficult to guarantee consistency. If the code to be compiled contains stuff like the following #ifdef __APPLE__ #include Python/Python.h #else #include Python.h #endif the compiler will compile against the latest framework installation it finds on the search path (probably /System/Library/Frameworks/Python.framework), but for linking whatever CMake (or the user by modifying the cache) chooses to pick will be used, be that the framework installation or some library-installation (Fink, MacPorts, /usr/lib, user-installed, ...). AFAIK all directories you give gcc with the -I option will be searched _before_ the standard include paths or C_INCLUDE_PATH. So I think you do have control over what is included. But I know almost nohting about all the compiling/linking stuff, so I might be wrong. -- Janosch ___ 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] Mixed Fortran and C++ projects in Visual Studio with Intel Fortran Compiler
On Fri, Jun 25, 2010 at 08:23:06AM -0400, cmake-requ...@cmake.org wrote: So is there any way in cmake to enforce Visual Studio to use link.exe instead of xilink.exe? grep -i LINK /usr/share/cmake-2.8/Modules/Platform/*|less yields a ton of link-related CMake variables during platform setup, thus something like CMAKE_LINKER should hopefully still be tweakable post-platform-setup and do the right thing. For linker flags, perhaps CMAKE_EXE_LINKER_FLAGS CMAKE_SHARED_LINKER_FLAGS CMAKE_MODULE_LINKER_FLAGS would be useful (but since you primarily want to change the linker binary perhaps you won't need these). OTOH your issue might be the split between Fortran and C++ components, in which case even CMAKE_LINKER might fail to help in all cases (in that case perhaps there's a target-specific property to set which defines the linker to use for the target). HTH, Andreas Mohr ___ 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] ctest and ctest -D Experimental give different results with VTK_DEBUG_LEAKS ON
Hello, I experienced a strange behaviour using ctest and I was wondering if it is a bug or the normal behaviour. 1) Build VTK with VTK_DEBUG_LEAKS to ON 2) Create a vtk leak in the test. 3) Run ctest on my machine, it tells me the test passed (doesn't catch vtk leaks). $ ctest -R 3d Test project /Users/nr52/workspace/gofigure2 Start 2: imageview3dTest 1/6 Test #2: imageview3dTest .. Passed0.76 sec Start 3: vtkviewimage3dtest 2/6 Test #3: vtkviewimage3dtest ... Passed0.33 sec Start 31: qgoimageview3dTest 3/6 Test #31: qgoimageview3dTest ... Passed2.66 sec Start 37: qgotabimageview3dTest 4/6 Test #37: qgotabimageview3dTest Passed2.47 sec Start 38: qgotabimageview3dwtTest 5/6 Test #38: qgotabimageview3dwtTest .. Passed3.80 sec Start 50: qgotabimageview3dwtTest2 6/6 Test #50: qgotabimageview3dwtTest2 . Passed3.66 sec 100% tests passed, 0 tests failed out of 6 Total Test time (real) = 13.70 sec 4) Run ctest -D Experimental to submit the test on the dashboard, it says the test is failing and reports the vtk leaks if you check on the dashboard. (http://my.cdash.org/viewTest.php?onlyfailedbuildid=77416) $ ctest -D Experimental -R 3d Site: starfish.megason-lab.hms Build name: OSX-10.5-gcc4.0.1 Create new tag: 20100625-1503 - Experimental Configure project Each . represents 1024 bytes of output . Size of output: 0K Build project Each symbol represents 1024 bytes of output. '!' represents an error and '*' a warning. .*. Size of output: 6K 0 Compiler errors 1 Compiler warnings Test project /Users/nr52/workspace/gofigure2 Start 2: imageview3dTest 1/6 Test #2: imageview3dTest .. Passed0.85 sec Start 3: vtkviewimage3dtest 2/6 Test #3: vtkviewimage3dtest ... Passed0.29 sec Start 31: qgoimageview3dTest 3/6 Test #31: qgoimageview3dTest ...***Failed2.60 sec Start 37: qgotabimageview3dTest 4/6 Test #37: qgotabimageview3dTest Passed2.08 sec Start 38: qgotabimageview3dwtTest 5/6 Test #38: qgotabimageview3dwtTest .. Passed3.27 sec Start 50: qgotabimageview3dwtTest2 6/6 Test #50: qgotabimageview3dwtTest2 .***Failed3.21 sec 67% tests passed, 2 tests failed out of 6 Total Test time (real) = 12.32 sec The following tests FAILED: 31 - qgoimageview3dTest (Failed) 50 - qgotabimageview3dwtTest2 (Failed) Performing coverage Cannot find any coverage files. Ignoring Coverage request. Submit files (using http) Using HTTP submit method Drop site:http://my.cdash.org/submit.php?project=GoFigure2 Uploaded: /Users/nr52/workspace/gofigure2/Testing/20100625-1503/ Build.xml Uploaded: /Users/nr52/workspace/gofigure2/Testing/20100625-1503/ Configure.xml Uploaded: /Users/nr52/workspace/gofigure2/Testing/20100625-1503/ Test.xml Submission successful Errors while running CTest Is it how it is supposed to work? Thanks, Nicolas ___ 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] Various problems deploying a python module
On Jun 25, 2010, at 10:05 AM, Janosch Peters wrote: On 2010-06-25 16:32:38 +0200, Mark Moll said: On Jun 25, 2010, at 9:11 AM, Janosch Peters wrote: Ok. But the python dilemma still remains: 1. FindPythonInterp and FindPythonLibs might still produce inconsistent results (e.g. libs and interpreter of different python versions) 2. AFAIK you cannot specify a specific python version you which to include/link I think someone on the list suggested to merge both modules into one, which would help making the results consistent. Is this (or any other solution) on your todo list? I suggested the merge, and proposed to add a function to check for the existence of python modules: http://www.cmake.org/pipermail/cmake/2010-June/037468.html On my OS X machine, the headers and libs for different python versions also exist in the more common UNIX places (/usr/include/python2.x, /usr/lib/libpython2.x.dylib, /usr/lib/python2.x/config/libpython2.x.a, and corresponding MacPorts locations). I don’t know of any way you can specify a specific version of a framework, so (at least for python) it seems easier to drop framework support altogether and just use the UNIX paths. I thought -framework 'path/to/the/framework/you/want/to/use' would work, but I havent tested it. Anyway, your find_package script looks very promising. I'll give it a try. What do you mean by UNIX-biased? Does it work only on Unix/Linux/OS X? Right. No attempt is made to use OS X-only frameworks or have it work correctly on Windows. -- Mark ___ 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] Mixed Fortran and C++ projects in Visual Studio with Intel Fortran Compiler
Marcus Sindermann wrote: Now we want to use update 65 of the Fortran compiler. This update enforces Visual Studio to use the Intel Fortran xilink for linking Fortran projects. CMake just generates the .vfproj file and then VS is responsible for the actual build. If the Fortran plugin is choosing to use xilink I do not know if there is much CMake can do about it. Can you modify the project file through the IDE by hand to chose the linker you want? -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] Mixed Fortran and C++ projects in Visual Studio with Intel Fortran Compiler
Andreas Mohr wrote: On Fri, Jun 25, 2010 at 08:23:06AM -0400, cmake-requ...@cmake.org wrote: So is there any way in cmake to enforce Visual Studio to use link.exe instead of xilink.exe? grep -i LINK /usr/share/cmake-2.8/Modules/Platform/*|less yields a ton of link-related CMake variables during platform setup, thus something like CMAKE_LINKER should hopefully still be tweakable post-platform-setup and do the right thing. Those are used by the Makefile generators. Once the VS project file is generated the IDE does its own thing. -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] [vtk-developers] ctest and ctest -D Experimental give different results with VTK_DEBUG_LEAKS ON
Yes, this is how it's supposed to work. The leaks are intentionally only detected as test failures when running a dashboard. Now that I'm saying this, though, I can't remember what the good reason was behind that intent. :-) Cheers, David On Fri, Jun 25, 2010 at 11:49 AM, Nicolas Rannou nicolas_ran...@hms.harvard.edu wrote: Hello, I experienced a strange behaviour using ctest and I was wondering if it is a bug or the normal behaviour. 1) Build VTK with VTK_DEBUG_LEAKS to ON 2) Create a vtk leak in the test. 3) Run ctest on my machine, it tells me the test passed (doesn't catch vtk leaks). $ ctest -R 3d Test project /Users/nr52/workspace/gofigure2 Start 2: imageview3dTest 1/6 Test #2: imageview3dTest .. Passed0.76 sec Start 3: vtkviewimage3dtest 2/6 Test #3: vtkviewimage3dtest ... Passed0.33 sec Start 31: qgoimageview3dTest 3/6 Test #31: qgoimageview3dTest ... Passed2.66 sec Start 37: qgotabimageview3dTest 4/6 Test #37: qgotabimageview3dTest Passed2.47 sec Start 38: qgotabimageview3dwtTest 5/6 Test #38: qgotabimageview3dwtTest .. Passed3.80 sec Start 50: qgotabimageview3dwtTest2 6/6 Test #50: qgotabimageview3dwtTest2 . Passed3.66 sec 100% tests passed, 0 tests failed out of 6 Total Test time (real) = 13.70 sec 4) Run ctest -D Experimental to submit the test on the dashboard, it says the test is failing and reports the vtk leaks if you check on the dashboard. (http://my.cdash.org/viewTest.php?onlyfailedbuildid=77416) $ ctest -D Experimental -R 3d Site: starfish.megason-lab.hms Build name: OSX-10.5-gcc4.0.1 Create new tag: 20100625-1503 - Experimental Configure project Each . represents 1024 bytes of output . Size of output: 0K Build project Each symbol represents 1024 bytes of output. '!' represents an error and '*' a warning. .*. Size of output: 6K 0 Compiler errors 1 Compiler warnings Test project /Users/nr52/workspace/gofigure2 Start 2: imageview3dTest 1/6 Test #2: imageview3dTest .. Passed0.85 sec Start 3: vtkviewimage3dtest 2/6 Test #3: vtkviewimage3dtest ... Passed0.29 sec Start 31: qgoimageview3dTest 3/6 Test #31: qgoimageview3dTest ...***Failed2.60 sec Start 37: qgotabimageview3dTest 4/6 Test #37: qgotabimageview3dTest Passed2.08 sec Start 38: qgotabimageview3dwtTest 5/6 Test #38: qgotabimageview3dwtTest .. Passed3.27 sec Start 50: qgotabimageview3dwtTest2 6/6 Test #50: qgotabimageview3dwtTest2 .***Failed3.21 sec 67% tests passed, 2 tests failed out of 6 Total Test time (real) = 12.32 sec The following tests FAILED: 31 - qgoimageview3dTest (Failed) 50 - qgotabimageview3dwtTest2 (Failed) Performing coverage Cannot find any coverage files. Ignoring Coverage request. Submit files (using http) Using HTTP submit method Drop site:http://my.cdash.org/submit.php?project=GoFigure2 Uploaded: /Users/nr52/workspace/gofigure2/Testing/20100625-1503/Build.xml Uploaded: /Users/nr52/workspace/gofigure2/Testing/20100625-1503/Configure.xml Uploaded: /Users/nr52/workspace/gofigure2/Testing/20100625-1503/Test.xml Submission successful Errors while running CTest Is it how it is supposed to work? Thanks, Nicolas ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.vtk.org/mailman/listinfo/vtk-developers ___ 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] Various problems deploying a python module
On 25. Jun, 2010, at 17:14 , Janosch Peters wrote: On 2010-06-25 16:58:47 +0200, Michael Wild said: However, I think it's really difficult to guarantee consistency. If the code to be compiled contains stuff like the following #ifdef __APPLE__ #include Python/Python.h #else #include Python.h #endif the compiler will compile against the latest framework installation it finds on the search path (probably /System/Library/Frameworks/Python.framework), but for linking whatever CMake (or the user by modifying the cache) chooses to pick will be used, be that the framework installation or some library-installation (Fink, MacPorts, /usr/lib, user-installed, ...). AFAIK all directories you give gcc with the -I option will be searched _before_ the standard include paths or C_INCLUDE_PATH. So I think you do have control over what is included. But I know almost nohting about all the compiling/linking stuff, so I might be wrong. The problem is the line #include Python/Python.h which resolves to /path/to/Python.framework/Headers/Python.h. No way to specify the version, only the framework location using the -F flag. 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] FindMPI for BlueGene/P (was: Better BlueGene/P and cross-compile support for CMake)
James Amundson wrote: This bug is a favorite of mine. It has been reported on the mailing list before. It is also in the bug tracker: http://public.kitware.com/Bug/view.php?id=10312nbn=1#bugnotes In each case a patch has been given to solve the problem. Nothing has happened, however. The fix is now in 'next'. See the other bug entry discussed elsewhere in this thread: http://www.cmake.org/Bug/view.php?id=9093 Parsing has been fixed for all flags now, not just -l: http://cmake.org/gitweb?p=cmake.git;a=log;h=d84cbd0f The reason nothing happened in response to the original bug report is that we have no active module maintainer for FindMPI: http://www.cmake.org/Wiki/CMake:Module_Maintainers The currently listed maintainer, Doug Gregor, has changed jobs and no longer maintains the module. If anyone wishes to volunteer to take over the role of module maintainer for FindMPI, please let me know! Thanks, -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] Mixed Fortran and C++ projects in Visual Studio with Intel Fortran Compiler
Brad King wrote: Can you modify the project file through the IDE by hand to chose the linker you want? s/chose/choose/ To be more clear, if it is possible to modify the project in the IDE by hand to change the linker, then we can teach CMake to generate the project file accordingly. If it is not possible to do by hand then I do not think CMake can do it either. -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] Issue w/ relative library paths between targets in CMake 2.8 / Visual Studio 9 2008
On 6/10/2010 2:34 PM, Ed Loper wrote:
I have a CMake project that works fine with CMake 2.6, but when I build
Visual Studio output with CMake 2.8, it doesn't seem to get the target
library linking information quite right. [...]
I managed to track down the cause of this problem. It can be reproduced
with the following minimal CMakeLists.txt file:
ADD_LIBRARY (Foo STATIC foo.c)
ADD_EXECUTABLE (Bar bar.c)
TARGET_LINK_LIBRARIES(Bar Foo)
INCLUDE_EXTERNAL_MSPROJECT(Foo ${CMAKE_BINARY_DIR}/Foo/Foo.vcproj)
The cause of the trouble is that the Foo target is getting re-used as
both a library and an external-ms-project. But with this ordering, we
don't get any warnings or errors; just a broken vcproj file. If the
INCLUDE_EXTERNAL_MSPROJECT command is moved to before the
TARGET_LINK_LIBRARY command, then we do get a (somewhat) helpful error
message saying you can't link to UTILITY targets.
(In the case of the cmakefiles I was working with, the call to
INCLUDE_EXTERNAL_MSPROJECT was in a totally different subdirectory from
the ADD_LIBRARY declaration, and the name conflict was unintentional.)
It looks to me like cmake already complains if you try to overload names
for some types of targets -- e.g., if I use both ADD_LIBRARY and
ADD_EXECUTABLE with the same target name, I get an error. I think it
would be a good idea to extend this to all target types. In particular,
it would have been very helpful if I got an error when
INCLUDE_EXTERNAL_MSPROJECT was called, since it's attempting to create a
new target with the same name as an existing target.
Thanks,
-Edward
___
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] Custom object files for intermediate build products
On Jun 24, 2010, at 2:40 AM, Michael Hertling wrote:
On 06/24/2010 08:29 AM, Tom Birch wrote:
Hi,
I'm trying to invoke the C compiler in cmake as would happen with an
add_excecutable command, but I don't want to generate an object file.
Basically I have a script which generates a c file, I want to compile that
file in the environment I've set up, while passing the -S flag. I then want
to run that .s file through another script to generate a header which will
then be a dependency of my main executable. Doing the scripts is easy with
add_custom_target, and I'm sure I could write all the magic to generate the
full compile command line myself, but isn't there some elegant way to
generate the a single compiler invocation that doesn't result in a dylib or
a binary, that works in a similar way to add_excecutable?
If you are using a Makefile generator I could offer this approach:
Place the following file cps as executable in CMAKE_SOURCE_DIR:
#!/bin/sh
d=$1; shift
while [ $1 != -- ]; do
cp $1 $d/$(basename $1 .o).s; shift
done
Now, look at the following CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(CPS C)
FILE(WRITE f1.c void f1(void){}\n)
FILE(WRITE f2.c void f2(void){}\n)
FILE(WRITE f3.c void f3(void){}\n)
ADD_EXECUTABLE(f f1.c f2.c f3.c)
SET_TARGET_PROPERTIES(f PROPERTIES
COMPILE_FLAGS -S
RULE_LAUNCH_LINK
${CMAKE_SOURCE_DIR}/cps ${CMAKE_BINARY_DIR} OBJECTS --
)
This uses the above-mentioned cps as a launch script for linking the
target f, but cps just copies the object files - delimited by --
- to the directory specified as the first argument, and of course, the
objects are in fact the assembler code files generated from the sources
by the -S flag which is imposed on the same target. Effectively, this
means you have a target producing .s files instead of an executable,
and everything else should be business as usual.
Yep, that was exactly what I needed, thanks!
Tom
'hope that helps.
Regards,
Michael
P.S.: The source file property GENERATED is useful in this context.
___
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] Better BlueGene/P and cross-compile support for CMake
Alexander Neundorf wrote: On Wednesday 23 June 2010, Todd Gamblin wrote: 3a. First, using this setup, FindMPI fails because the last library it needs is in /bgsys/drivers/ppcfloor/runtime/SPI, not /bgsys/drivers/ppcfloor/runtime/SPI/lib. CMAKE_FIND_ROOT_PATH seems to assume that its elements are just above a lib directory, but that's not how things are structured on BG/P (you can blame IBM). So, if I just use the root path for searching, find_library fails for libs in runtime/SPI. I guess you need a special Platform/BlueGeneP.cmake file, which not simply includes UnixPaths.cmake, but sets some special directories. Please add a bug report for this on http://public.kitware.com/Bug/ too. Good idea. There is a distinction to understand here: (1) CMAKE_FIND_ROOT_PATH is meant for cross-compiling and should appear only in toolchain files. It re-roots all search paths. Usually the goal is to find libraries only from the target platform SDK (and not the host), which is why we suggest using set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) Typically CMAKE_FIND_ROOT_PATH should be set to the *top* of the SDK tree, such as /bgsys/drivers/ppcfloor in your case. (2) CMAKE_SYSTEM_PREFIX_PATH, CMAKE_SYSTEM_LIBRARY_PATH, and similar variables are meant for controlling the search *within* the target platform SDK to find different types of files. See help for find_library, find_program, and find_path for specific details. This is where the prefix/lib assumption occurs: - find_library looks in CMAKE_SYSTEM_PREFIX_PATH/lib - find_library looks in CMAKE_SYSTEM_LIBRARY_PATH, but the Modules/Platform/UnixPaths.cmake file sets this variable with /lib at the end of most of its paths. What Alex suggests is to create a Modules/Platform/BlueGeneP.cmake file that defines CMAKE_SYSTEM_LIBRARY_PATH to something like /runtime/SPI and other paths relative to CMAKE_FIND_ROOT_PATH entries. This tells CMake how to find libraries within the target platform SDK. IIRC, you can try this out by setting CMAKE_SYSTEM_LIBRARY_PATH directly in your toolchain file, but I do not remember for sure if it works there. -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] Issue w/ relative library paths between targets in CMake 2.8 / Visual Studio 9 2008
On Fri, Jun 25, 2010 at 3:00 PM, Ed Loper elo...@bbn.com wrote:
On 6/10/2010 2:34 PM, Ed Loper wrote:
I have a CMake project that works fine with CMake 2.6, but when I build
Visual Studio output with CMake 2.8, it doesn't seem to get the target
library linking information quite right. [...]
I managed to track down the cause of this problem. It can be reproduced
with the following minimal CMakeLists.txt file:
ADD_LIBRARY (Foo STATIC foo.c)
ADD_EXECUTABLE (Bar bar.c)
TARGET_LINK_LIBRARIES(Bar Foo)
INCLUDE_EXTERNAL_MSPROJECT(Foo ${CMAKE_BINARY_DIR}/Foo/Foo.vcproj)
The cause of the trouble is that the Foo target is getting re-used as
both a library and an external-ms-project. But with this ordering, we don't
get any warnings or errors; just a broken vcproj file. If the
INCLUDE_EXTERNAL_MSPROJECT command is moved to before the
TARGET_LINK_LIBRARY command, then we do get a (somewhat) helpful error
message saying you can't link to UTILITY targets.
(In the case of the cmakefiles I was working with, the call to
INCLUDE_EXTERNAL_MSPROJECT was in a totally different subdirectory from the
ADD_LIBRARY declaration, and the name conflict was unintentional.)
It looks to me like cmake already complains if you try to overload names
for some types of targets -- e.g., if I use both ADD_LIBRARY and
ADD_EXECUTABLE with the same target name, I get an error. I think it would
be a good idea to extend this to all target types. In particular, it would
have been very helpful if I got an error when INCLUDE_EXTERNAL_MSPROJECT was
called, since it's attempting to create a new target with the same name as
an existing target.
I agree wholeheartedly. Thanks for the easy-to-repro case. Would you mind
logging a bug in the bug tracker for this?
Name collisions between any two CMake targets should definitely not be
allowed (i.e. -- be a configure error) within a single CMake binary tree...
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] FindMPI for BlueGene/P
On 06/25/2010 01:40 PM, Brad King wrote: James Amundson wrote: This bug is a favorite of mine. It has been reported on the mailing list before. It is also in the bug tracker: http://public.kitware.com/Bug/view.php?id=10312nbn=1#bugnotes In each case a patch has been given to solve the problem. Nothing has happened, however. The fix is now in 'next'. See the other bug entry discussed elsewhere in this thread: http://www.cmake.org/Bug/view.php?id=9093 Great. Parsing has been fixed for all flags now, not just -l: http://cmake.org/gitweb?p=cmake.git;a=log;h=d84cbd0f Even better. Thanks, Jim ___ 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] Various problems deploying a python module
On 2010-06-25 18:36:06 +0200, Michael Wild said: AFAIK all directories you give gcc with the -I option will be searched _before_ the standard include paths or C_INCLUDE_PATH. So I think you do have control over what is included. But I know almost nohting about all the compiling/linking stuff, so I might be wrong. The problem is the line #include Python/Python.h which resolves to /path/to/Python.framework/Headers/Python.h. No way to specify the version, only the framework location using the -F flag. Okay. But as Mark Moll pointed out, we could just ignore the -F flag and use plain Unix include/library paths. ___ 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] Better BlueGene/P and cross-compile support for CMake
On Jun 25, 2010, at 12:06 PM, Brad King wrote: Alexander Neundorf wrote: On Wednesday 23 June 2010, Todd Gamblin wrote: 3a. First, using this setup, FindMPI fails because the last library it needs is in /bgsys/drivers/ppcfloor/runtime/SPI, not /bgsys/drivers/ppcfloor/runtime/SPI/lib. CMAKE_FIND_ROOT_PATH seems to assume that its elements are just above a lib directory, but that's not how things are structured on BG/P (you can blame IBM). So, if I just use the root path for searching, find_library fails for libs in runtime/SPI. I guess you need a special Platform/BlueGeneP.cmake file, which not simply includes UnixPaths.cmake, but sets some special directories. Please add a bug report for this on http://*public.kitware.com/Bug/ too. Good idea. There is a distinction to understand here: (1) CMAKE_FIND_ROOT_PATH is meant for cross-compiling and should appear only in toolchain files. It re-roots all search paths. Usually the goal is to find libraries only from the target platform SDK (and not the host), which is why we suggest using set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) Typically CMAKE_FIND_ROOT_PATH should be set to the *top* of the SDK tree, such as /bgsys/drivers/ppcfloor in your case. This makes sense, but it's actually slightly more complicated for BG/P. I just got off the phone with our lead BG sysadmin (Adam Bertsch) about this, and here's what I got about the layout of that directory: /bgsys/drivers/ppcfloor This is the root of the BG system software release (driver in IBM-speak), and it contains files for the frontends, the I/O nodes, and the compute nodes. We probably don't want to make this the system root for the backend, because it would allow other types of binaries into the build. /bgsys/drivers/ppcfloor/mcp-2.6.16.60 This is the root of the I/O node system image. This is the 32-bit PPC linux (pretty sure it's SuSE too) that runs on the I/O nodes (IONs) of BG/P. I do tools development, and it's possible to run daemons like TotalView on the IONs, so I might at some point try to make a platform/toolchain file for this, but not in the near future, if at all. This shouldn't go in the plain BG/P toolchain file. FYI -- the version number here is the linux kernel version, which *could* change, but typically IBM doesn't upgrade the BG ION kernels during a particular BG product's lifetime, or at least they haven't yet, for L or P. Now, for the Compute Nodes (CNs). Adam essentially said that there *is* no formal documentation about where you should look to find CN system libraries. However, there are the MPI compiler scripts in /bgsys/drivers/ppcfloor/comm/bin. These were written by Argonne and are now included with the BG driver distribution, and they have to link against all the BG system libraries. I ran all the compilers with -show, and unioned all the args I was getting with that command. This narrows it down to a few directories: /bgsys/drivers/ppcfloor/comm/default/lib /bgsys/drivers/ppcfloor/comm/sys/lib /bgsys/drivers/ppcfloor/runtime/SPI That's it. Those are really the only backend directories that contain libraries used by apps. The CN Kernel (CNK) OS is minimal, so this makes sense, and if you look in those directories, they contain MPI libs and various lower-level comm APIs like DCMF, which BG uses. Now, there are also directories for the particular toolchains, and I'm not sure you care about these, because the BG compilers already link against the libraries in these directories. For GNU, the backend compiler runtime libs are in: /bgsys/drivers/ppcfloor/gnu-linux And for XL compilers, the runtime libraries seem to be in: /opt/ibmcmp/compiler/bg/version/bglib I believe that these things are already put either in the runtime path by the compiler (or they're somewhere in the CNK runtime load path), so I don't think they belong in a toolchain file. (2) CMAKE_SYSTEM_PREFIX_PATH, CMAKE_SYSTEM_LIBRARY_PATH, and similar variables are meant for controlling the search *within* the target platform SDK to find different types of files. See help for find_library, find_program, and find_path for specific details. This is where the prefix/lib assumption occurs: - find_library looks in CMAKE_SYSTEM_PREFIX_PATH/lib - find_library looks in CMAKE_SYSTEM_LIBRARY_PATH, but the Modules/Platform/UnixPaths.cmake file sets this variable with /lib at the end of most of its paths. Ok, given all that I've said above, there is still a small problem. The BG CNK system libraries are rooted in /bgsys/drivers/ppcfloor/, but /lib and /lib64 under that prefix are FRONT END libraries. This means that you really shouldn't look in those two directories. /lib64 you don't need to worry about, since the BG backend is 32-bit. and /lib you *probably* don't need to worry about
[CMake] Eliminating spurious dependencies
I'm using add_excecutable to generate a .s file which I then parse to generate
a header file. This all works fine and all the dependencies seem to be working,
but it gets built every time, even if nothing has changed.
I have a function to generate the asm file:
function (make_asm_file source dest defs flags)
set_source_files_properties(
${source}
PROPERTIES
COMPILE_DEFINITIONS ${${defs}}
COMPILE_FLAGS ${${flags}} -S
)
add_executable (
${dest}
EXCLUDE_FROM_ALL
${source}
)
set_target_properties(
${dest}
PROPERTIES
OUTPUT_NAME ${dest}
RULE_LAUNCH_LINK sh build_tools/copier.sh ${CMAKE_BINARY_DIR}
OBJECTS --
)
endfunction(make_asm_file)
and I invoke that, and then add a custom command to convert the .s into a .h
like this:
make_asm_file(${input_c} ${output_s} c_defs c_flags)
add_custom_command (
OUTPUT ${header_path}
COMMAND ./make_header ${header_path} ${dest}
DEPENDS ${output_s}
)
and then I use set_source_file_properties(OBJECT_DEPENDS) to make the sources
depend on this generated header.
Every time I get type make (even on incremental builds) I get
[ 0%] Built target genassym.c.s
but I only see the custom command on a build when the header hasn't previously
been generated, i.e.
[ 1%] Generating assym.h
So my question is, what is it about this invocation of add_excecutable that
makes it always run? Shouldn't EXCLUDE_FROM_ALL get rid of that?
cheers,
Tom
___
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] Various problems deploying a python module
On 06/25/2010 04:11 PM, Janosch Peters wrote: On 2010-06-25 15:45:37 +0200, Michael Hertling said: On 06/25/2010 03:17 PM, Janosch Peters wrote: On 2010-06-21 07:01:36 +0200, Michael Hertling said: 8d87d12 What's that? Leet speak? No, these are the first seven and sufficiently unambiguous digits of the SHA-1 sum of the commit in CMake's Git repository that removes the framework related lines from FindPythonLibs.cmake Ok. But the python dilemma still remains: 1. FindPythonInterp and FindPythonLibs might still produce inconsistent results (e.g. libs and interpreter of different python versions) 2. AFAIK you cannot specify a specific python version you which to include/link I think someone on the list suggested to merge both modules into one, which would help making the results consistent. Is this (or any other solution) on your todo list? Not on mine - I don't feel sufficiently experienced w.r.t. python, but when thinking about a combined FindPython.cmake, remind the following: http://public.kitware.com/Bug/view.php?id=2257, note #11766 http://www.mail-archive.com/cmake@cmake.org/msg27382.html Therefore, my thoughts about a FindPython.cmake are: 1) FindPython.cmake uses FIND_PACKAGE()'s COMPONENTS option and respects a specified version. 2) There're at least the components interpreter and libraries, and possibly more for modules. 3) Requesting no components at all means requesting interpreter and libraries. 4) Requesting interpreter and libraries means requesting the libraries accompanying the requested interpreter. 5) Requesting solely libraries means looking for the libraries without referring to an interpreter. One of the first apparent problems is how to learn the version when none is specified explicitly since it is necessary to look for the libraries. My suggestion is to provide a variable PYTHON_NATIVE to indicate an interpreter's executability, so the latter can be used to figure out the whole library stuff. Otherwise, one could try to extract the version from the interpreter's name, or try to find an unambiguous library directory. In summary, this may be roughly pseudo-coded as: IF(Python_FIND_COMPONENTS is empty) SET(Python_FIND_COMPONENTS interpreter libraries) ENDIF() IF(Python_FIND_COMPONENTS contains interpreter) # Search an interpreter and respect Python_FIND_VERSION et al. ENDIF() IF(Python_FIND_COMPONENTS contains libraries) IF(Python_FIND_COMPONENTS contains interpreter) # User requested interpreter and libraries, so the latters must # belong to the former; one may be guided by the already found # interpreter, but think whether and when you execute it: IF(PYTHON_NATIVE) # Run the interpreter to locate the associated libraries. ELSEIF(Python_FIND_VERSION) # Search libraries of the requested version. ELSE() # Try to extract the version from the interpreter's name, # e.g. python2.6, or as a last resort, try to find a # single and, thus, unambiguous library directory. ENDIF() ELSE() # User requested solely the libraries, so don't rely on an # interpreter being available; search the libraries as # usual and respect Python_FIND_VERSION et al. ENDIF() ENDIF() So, the user could issue, e.g., SET(PYTHON_NATIVE TRUE) FIND_PACKAGE(Python) to get a consistent native interpreter/libraries combination, or FIND_PACKAGE(Python 2.6 COMPONENTS interpreter libraries) to get a consistent 2.6 interpreter/libraries combination, or FIND_PACKAGE(Python 2.6 COMPONENTS interpreter) FIND_PACKAGE(Python 2.6 COMPONENTS libraries) to get a certain 2.6 interpreter and certain 2.6 libraries, or FIND_PACKAGE(Python 2.5 COMPONENTS interpreter) FIND_PACKAGE(Python 2.4 COMPONENTS libraries) to get the 2.5 interpreter and the 2.4 libraries. Anyway, one should not take it too lightly; IMO, writing a fully featured, reliable and consistent FindPython.cmake is rather a nontrivial task. 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] Eliminating spurious dependencies
On 06/26/2010 01:09 AM, Tom Birch wrote:
I'm using add_excecutable to generate a .s file which I then parse to
generate a header file. This all works fine and all the dependencies seem to
be working, but it gets built every time, even if nothing has changed.
I have a function to generate the asm file:
function (make_asm_file source dest defs flags)
set_source_files_properties(
${source}
PROPERTIES
COMPILE_DEFINITIONS ${${defs}}
COMPILE_FLAGS ${${flags}} -S
)
add_executable (
${dest}
EXCLUDE_FROM_ALL
${source}
)
set_target_properties(
${dest}
PROPERTIES
OUTPUT_NAME ${dest}
RULE_LAUNCH_LINK sh build_tools/copier.sh ${CMAKE_BINARY_DIR}
OBJECTS --
)
endfunction(make_asm_file)
and I invoke that, and then add a custom command to convert the .s into a .h
like this:
make_asm_file(${input_c} ${output_s} c_defs c_flags)
add_custom_command (
OUTPUT ${header_path}
COMMAND ./make_header ${header_path} ${dest}
DEPENDS ${output_s}
)
and then I use set_source_file_properties(OBJECT_DEPENDS) to make the sources
depend on this generated header.
Every time I get type make (even on incremental builds) I get
[ 0%] Built target genassym.c.s
but I only see the custom command on a build when the header hasn't
previously been generated, i.e.
[ 1%] Generating assym.h
So my question is, what is it about this invocation of add_excecutable that
makes it always run? Shouldn't EXCLUDE_FROM_ALL get rid of that?
Are you really sure that the targets in question get rebuilt each time
you run make? The message Built target ... appears if the target is
found to be up to date regardless if it has been rebuilt afore or not
whereas the Generating ... message for custom commands appears only
if the command's output is actually regenerated. So, could you check
with make VERBOSE=1 for lines like Building ..., Compiling ...
or Linking ...? These are the ones indicating the expensive
operations.
BTW, setting COMPILE_FLAGS -S as a source file property is somewhat
risky: If you ever need the concerned files for a usual compilation
they will be just translated to assembler code at that time, too,
making the subsequent link operation fail. Perhaps, you should
prefer to impose the -S as a COMPILE_FLAGS target property.
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] Better BlueGene/P and cross-compile support for CMake
On Jun 23, 2010, at 2:10 PM, Alexander Neundorf wrote: 3a. First, using this setup, FindMPI fails because the last library it needs is in /bgsys/drivers/ppcfloor/runtime/SPI, not /bgsys/drivers/ppcfloor/runtime/SPI/lib. CMAKE_FIND_ROOT_PATH seems to assume that its elements are just above a lib directory, but that's not how things are structured on BG/P (you can blame IBM). So, if I just use the root path for searching, find_library fails for libs in runtime/SPI. I guess you need a special Platform/BlueGeneP.cmake file, which not simply includes UnixPaths.cmake, but sets some special directories. Please add a bug report for this on http://*public.kitware.com/Bug/ too. Ok, I've created a bug report for this here: http://public.kitware.com/Bug/bug_view_advanced_page.php?bug_id=10897 Looking at the other bugs, I feel like I may have set the severity a little high, so feel free to reduce. -Todd___ 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] Better BlueGene/P and cross-compile support for CMake
Some small additions to the path information I posted below: I believe the original GNU/POSIX runtime libraries for the compute nodes are located here: /bgsys/drivers/ppcfloor/gnu-linux/powerpc-bgp-linux So you'll need this directory in your prefixes to detect things like libpthread (which you ned for MPI on BG/P). BG/P also has added support for python apps to execute on the compute nodes, and the IBM driver ships with a python installation. For whatever reason, they install the CNK python runtime libraries it in under this prefix: /bgsys/drivers/ppcfloor/gnu-linux That will need to be in your paths for python development. I'm unsure if anyone's done much in CMake involving cross-compiling python builds, and I'm pretty unfamiliar with how CMake deals with python projects. I'm assuming the python support in CMake knows how to search lib/pythonVERSION directories, but I'm not sure if there is more that would needs to be done to get python working seamlessly. -Todd On Jun 25, 2010, at 4:08 PM, Todd Gamblin wrote: This makes sense, but it's actually slightly more complicated for BG/P. I just got off the phone with our lead BG sysadmin (Adam Bertsch) about this, and here's what I got about the layout of that directory: /bgsys/drivers/ppcfloor This is the root of the BG system software release (driver in IBM-speak), and it contains files for the frontends, the I/O nodes, and the compute nodes. We probably don't want to make this the system root for the backend, because it would allow other types of binaries into the build. /bgsys/drivers/ppcfloor/mcp-2.6.16.60 This is the root of the I/O node system image. This is the 32-bit PPC linux (pretty sure it's SuSE too) that runs on the I/O nodes (IONs) of BG/P. I do tools development, and it's possible to run daemons like TotalView on the IONs, so I might at some point try to make a platform/toolchain file for this, but not in the near future, if at all. This shouldn't go in the plain BG/P toolchain file. FYI -- the version number here is the linux kernel version, which *could* change, but typically IBM doesn't upgrade the BG ION kernels during a particular BG product's lifetime, or at least they haven't yet, for L or P. Now, for the Compute Nodes (CNs). Adam essentially said that there *is* no formal documentation about where you should look to find CN system libraries. However, there are the MPI compiler scripts in /bgsys/drivers/ppcfloor/comm/bin. These were written by Argonne and are now included with the BG driver distribution, and they have to link against all the BG system libraries. I ran all the compilers with -show, and unioned all the args I was getting with that command. This narrows it down to a few directories: /bgsys/drivers/ppcfloor/comm/default/lib /bgsys/drivers/ppcfloor/comm/sys/lib /bgsys/drivers/ppcfloor/runtime/SPI That's it. Those are really the only backend directories that contain libraries used by apps. The CN Kernel (CNK) OS is minimal, so this makes sense, and if you look in those directories, they contain MPI libs and various lower-level comm APIs like DCMF, which BG uses. Now, there are also directories for the particular toolchains, and I'm not sure you care about these, because the BG compilers already link against the libraries in these directories. For GNU, the backend compiler runtime libs are in: /bgsys/drivers/ppcfloor/gnu-linux And for XL compilers, the runtime libraries seem to be in: /opt/ibmcmp/compiler/bg/version/bglib ___ 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] An observation about CTest
Hi all, I tend to agree to this observation in general about CMake too. I had to do a lot of reading and experimentation to make it do what I wanted, even though at the end of the day, the resulting CMakeList.txt file is very simple. I do understand why this is so. As can be seen by the type of requests on this list and your responses to them, Cmake is supporting a LOT of different types of projects and needs. So while it won't be possible to reduce the number of commands and variables, it would help to have better documentation -- with examples for each command and variable, examples for typical stuff people need, etc. I had to struggle even to do simple things like specifying custom compiler and linker flags for Visual Studio and GCC. Thanks and best regards - Alok Date: Thu, 24 Jun 2010 16:59:56 -0400 From: christian.con...@navy.mil To: cmake@cmake.org Subject: [CMake] An observation about CTest Hi guys, First off, I'd like to give my heartfelt thanks to everyone who's helped me figure out how to use CTest in the past few weeks. I'm very grateful to you and to those who develop CTest. I'd like to offer one piece of constructive criticism about ctest. If found learning how to use it to be very difficult, in part because controlling ctest involves setting a lot of variables whose purposes aren't clearly documented. But the bigger concern I have is that it's not clear which of those variables are meant to be used by people like me, and which are meant to be treated as implementation details that may change from one release to the next of CTest. This makes it hard for me (and perhaps others) to control ctest, because I don't want to rely on a variable or behavior that's considered internal and likely to change in the next release. I guess what I'm arguing for is a clearer delineation of CTest's public interface vs. its internal implementation details, so that users like me don't accidentally cross that line. Thanks again, Christian P.S. My final solution was to set the BUILDNAME cmake variable on a cmake command-line, and later on to just run ctest -D NightlyStart ... -D NightlySubmit. Works like a charm. _ The New Busy is not the old busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_3___ 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.1-1508-ge548a88
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 e548a88579a021598bcf0fc703246d265e7cc605 (commit)
via 696a0af22022c6d629d67fcff2c7e779c917e187 (commit)
from 358773feafe7acb4305038ed53d79c854348bc2d (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=e548a88579a021598bcf0fc703246d265e7cc605
commit e548a88579a021598bcf0fc703246d265e7cc605
Merge: 358773f 696a0af
Author: Bill Hoffman bill.hoff...@kitware.com
Date: Fri Jun 25 12:57:34 2010 -0400
Merge branch 'disable_gcc33_onfree_bsd' into next
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=696a0af22022c6d629d67fcff2c7e779c917e187
commit 696a0af22022c6d629d67fcff2c7e779c917e187
Author: Bill Hoffman bill.hoff...@kitware.com
Date: Fri Jun 25 12:54:16 2010 -0400
Disable gcc 33 on OpenBSD because it crashes CPack by default.
Make sure no one tries to use gcc 33 based tools to build CMake.
This is because a cpack test failed with a crash. The crash
seems to be caused by the stack checking code on by default in
OpenBSD. The crash is in some stl code. The problem is fixed
with newer gcc compilers on OpenBSD.
diff --git a/CMakeLists.txt b/CMakeLists.txt
index bd90163..8b41cc3 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -17,6 +17,21 @@ ENDIF(COMMAND CMAKE_POLICY)
MARK_AS_ADVANCED(CMAKE_BACKWARDS_COMPATIBILITY)
+IF(CMAKE_CXX_PLATFORM_ID MATCHES OpenBSD)
+ EXECUTE_PROCESS(COMMAND ${CMAKE_CXX_COMPILER}
+${CMAKE_CXX_COMPILER_ARG1} -dumpversion
+OUTPUT_VARIABLE _GXX_VERSION
+ )
+ STRING(REGEX REPLACE ([0-9])\\.([0-9])(\\.[0-9])? \\1\\2
+_GXX_VERSION_SHORT ${_GXX_VERSION})
+ IF(_GXX_VERSION_SHORT EQUAL 33)
+MESSAGE(FATAL_ERROR
+ GXX 3.3 on OpenBSD is known to cause CPack to Crash.\n
+ Please use GXX 4.2 or greater to build CMake on OpenBSD\n
+ ${CMAKE_CXX_COMPILER} version is: ${_GXX_VERSION})
+ ENDIF()
+ENDIF()
+
# Allow empty endif() and such with CMake 2.4.
SET(CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS 1)
---
Summary of changes:
CMakeLists.txt | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
