Re: [CMake] cmake + OSX + gfortran + 64bit problem
Okay, thanks, I'll have a look. But isn't this also CMake bug? In most other cases it seems to do a good job of knowing which flags to use for different compilers. > -Original Message- > From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On > Behalf Of j s > Sent: Thursday, December 16, 2010 0:00 > To: Michael Jackson > Cc: cmake Mailing List > Subject: Re: [CMake] cmake + OSX + gfortran + 64bit problem > > I use the compiler from the att site. It does support the arch flags, > as they have applied the patches. They also explicitly state why you > should not use the gfortran from the HPC site. I avoid all MacPorts > compilers, as they make some bad packaging mistakes, such as linking > against their own version of the c runtimes. > > Juan smime.p7s Description: S/MIME cryptographic signature ___ 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 + OSX + gfortran + 64bit problem
Thanks, but a guy on the gfortran mailing list makes it sound like they have no intention to support "-arch x86_64" on the Mac. I need to find a solution that will work on stock versions of gfortran, unfortunately. > That probably depends which gfortran you are using on the Mac. > I've used the -arch flag with gfortran before, and at the time, I > thought the > only multi-arch gfortran available to download/install took the -arch > flag. smime.p7s Description: S/MIME cryptographic signature ___ 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] cmake + OSX + gfortran + 64bit problem
Here's what I've got: Cmake: 2.8.3 OS X: 10.5.x gfortran: 4.5.1 I'm trying to build a Fortran program on OS X using CMake. I'm trying to write CMakeLists.txt files that can handle either the GNU fortran compiler or the Intel fortran compiler. When set CMAKE_OSX_ARCHITECTURES to x86_64, the resulting makefiles end up supplying "-arch x86_64" to the gfortran command line. That flag is appropriate for the Intel fortran compiler but it isn't valid for gfortran, even on a Mac. It should be "-m64". Does anyone know of a good way around this? Christian Convey Scientist, NUWC Division Newport 1176 Howell St., Newport, RI 02842 email: christian.con...@navy.mil phone: (401) 832-6824 fax: (401) 832-4749 smime.p7s Description: S/MIME cryptographic signature ___ 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] Creating CMakeLists files from Solutions, Projects and Makefiles
Funny timing - I just did that today, at least in a crude manner. Long story short: On Unix/Linux/Mac, you can use the command-line tools (grep, sed, cut, xargs, etc.) to get the list of all source file that comprise the solutions' projects. If your needs aren't too fancy, it's pretty trivial to make a simple CMakeLists.txt file out of that list of files. Granted it's just a start, but my point is, it may not me as tough of a nut to crack as you fear, at least for relatively simple projects. > -Original Message- > From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On > Behalf Of Paul Dean > Sent: Tuesday, December 07, 2010 14:14 > To: cmake@cmake.org > Subject: [CMake] Creating CMakeLists files from Solutions,Projects and > Makefiles > > I've been using CMAKE for a few years now and I absolutley LOVE it. > It makes my life as a programmer so much easier to be able to generate > project files on any platform. > > What hurts is doing the reverse. I can't count how many hours I've > spent converting Solutions, Projects and Makefiles into CmakeLists > files. > > I think if CMAKE could generate CMakeLists files from Solutions, > Projects and Makefiles, it would be the ULTIMATE make system. > Just think. Any time you run into some sorcecode that does not have a > CMakeFile, you could generate it from the Makefile or Project. > > I can't imagine any programmer that would not love that ability. I > think it would be something great to add to CMAKE. > What are everyones thoughts on that? > > Paul Dean > I.T. Professional > 714-341-4519 > p...@pdcomputertech.com > aquawic...@hotmail.com > > > smime.p7s Description: S/MIME cryptographic signature ___ 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] Best way to sniff for Fortran compiler?
Any suggest for the most-proper way, in a CMakeLists.txt file, to determine whether the Intel vs. GNU fortran compiler will be used? I need to use different sets of source files, and different compiler flags, depending on that detail. Christian Convey Scientist, NUWC Division Newport 1176 Howell St., Newport, RI 02842 email: christian.con...@navy.mil phone: (401) 832-6824 fax: (401) 832-4749 smime.p7s Description: S/MIME cryptographic signature ___ 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 support for Coverity Prevent?
I've got a license for Coverity Prevent (a pretty decent static analysis tool). Although Prevent has a web interface, I was thinking that it would also be nice to run Prevent on a nightly basis and have the results appear on the same dashboard populated by my nightly ctest runs. Has anyone worked out a good way to do this? Thanks, Christian smime.p7s Description: S/MIME cryptographic signature ___ 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 Alan, Thanks, I wasn't aware of the shift towards the use of FUNCTIONs. Because of the developers I need to support, I've been mosting working with CMake 2.6. I didn't realize that this was one of the things 2.8 brought to the table. - Christian > -Original Message- > From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca] > Sent: Sunday, June 27, 2010 16:49 > To: Convey, Christian J CIV NUWC NWPT > Cc: alokgo...@hotmail.com; cmake@cmake.org > Subject: Re: [CMake] An observation about CTest > > Your remarks focus on old-fashioned macros so it is possible > you are not aware of functions? As far as I know, most or all > macros can be replaced by functions which do have the nice > property of not polluting the global namespace. So newly > developed build systems should use functions wherever > possible, and certainly for old CMake-based build systems I > am associated with I am trying to move to functions as time permits. > > Here are some rough counts of functions and macros actually > contained in 2.8.x: > > ir...@raven> grep -i function cmake-2.8/Modules/*.cmake |grep > -v '#' |wc -l > 263 > ir...@raven> grep -i macro cmake-2.8/Modules/*.cmake |grep -v > '#' |wc -l > 337 > > Those numbers should be divided by roughly a factor of two > (because of ENDFUNCTION and ENDMACRO) to get approximate > counts of functions and macros. > > Clearly, the replacement of macros by functions is well on > its way for 2.8.x, but the process is still far from > completed. Once it is complete, however, the global > namespace will be much less polluted. > > Another namespace remark is that subdirectory variables do > not pollute the global namespace of their parent directories. > > So the global namespace pollution issue is not as bad as you > have outlined and because of functions is steadily improving. > > Alan smime.p7s Description: S/MIME cryptographic signature ___ 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 Eric, Thanks for all those details. I wasn't aware that CMake drew a distinction between macros and functions. I'll try to have a look at the ML archives. - Christian > -Original Message- > From: Eric Noulard [mailto:eric.noul...@gmail.com] > Sent: Sunday, June 27, 2010 16:42 > To: Convey, Christian J CIV NUWC NWPT > Cc: alokgo...@hotmail.com; cmake@cmake.org > Subject: Re: [CMake] An observation about CTest > > 2010/6/27 Convey, Christian J CIV NUWC NWPT > : > > I don't expect a lot of support for what I'm about to say, > but I think it's perhaps worth saying anyway... > > > > It seems like CMake's and CTest's have outgrown their > scripting languages. > > > > As far as I can tell, all CMake/CTest variables are either macro > > formal parameters, or variables in a single global > namespace. I think > > one consequence of this is that macro invocations make their > > contributions primarily by modifying variables in the global > > namespace. As people discovered in the 1970's and 1980's, the > > confusion caused by this approach (global variables) can be > so extensive that it's worthwhile to change coding pracices > (structured programming, etc.), and possibly to improve the > base language as well. > > I think you should dive into the Mailing List archive because > there have been several valuable discussion about CMake > evolution including the "replacement/extension" > of CMake scripting > language with "full language" like Lua or Python. > > > But even better would be enhancing the CMake scripting language to > > support local variables in macros, and possible package-scoped > > variables as well. This clarifies the intended interface > that certain > > macro packages are intended to provide, because variables > intended as implementation details would be in a namespace > inaccessible to the script that invokes those macros. > > CMake is offering scope from a parent/child point of view > including setting variable for your parent with set( > PARENT_SCOPE) this was indeed provided after lengthly ML discussion. > > Concerning "local variables" you should have a look at the > difference between a "MACRO" and a "FUNCTION" this may > already gives you part of what you want. > > Then as far as I can tell CMake scripting is no-where near a > "must not evolve" language many improvement has been put in > since I began to use CMake 2.2.x (can't remember X) even the > introduction of "POLICY" which each backward compatibility. > > So I think you may not hope to have ALL what you require in > CMake after a message on this ML be you will certainly have > feedback and may be new feature if there is a consensus and > some proof of concept patch provided. > > -- > Erk > Membre de l'April - « promouvoir et défendre le logiciel > libre » - http://www.april.org > smime.p7s Description: S/MIME cryptographic signature ___ 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
I don't expect a lot of support for what I'm about to say, but I think it's
perhaps worth saying anyway...
It seems like CMake's and CTest's have outgrown their scripting languages.
As far as I can tell, all CMake/CTest variables are either macro formal
parameters, or variables in a single global namespace. I think one consequence
of this is that macro invocations make their contributions primarily by
modifying variables in the global namespace. As people discovered in the
1970's and 1980's, the confusion caused by this approach (global variables) can
be so extensive that it's worthwhile to change coding pracices (structured
programming, etc.), and possibly to improve the base language as well.
It the CMake scripting language wouldn't be allowed to change, then I'd want to
consider a change to CMake coding style:
Any macro invocation that's intended to update global state (for example,
"INCLUDE_DIRECTORIES(foo)") should only be allowed to modify global-namespace
variables that are explicitly named as parameters to the macro call. For
example:
"INCLUDE_DIRECTORIES("foo", MY_DIRECTORIES_LIST)".
But even better would be enhancing the CMake scripting language to support
local variables in macros, and possible package-scoped variables as well. This
clarifies the intended interface that certain macro packages are intended to
provide, because variables intended as implementation details would be in a
namespace inaccessible to the script that invokes those macros.
Another possiblity, which I'm sure has been considered, would be to stop having
CMake and CTest provide their own scripting languages, and instead make them be
libraries in some other, more advanced scripting language like Python.
Anyway, that's just my two cents as someone who's been casually using CMake for
the past two or three years.
- Christian
> 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
smime.p7s
Description: S/MIME cryptographic signature
___
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] 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. smime.p7s Description: S/MIME cryptographic signature ___ 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] Ways of setting CTEST_BUILD_NAME
Yeah, thanks, that makes sense. Actually, another thing I like about specifying BUILDNAME on the command line is because the shell script that invokes "cmake" is also a very opportune place to compute the build name. - C > -Original Message- > From: David Cole [mailto:david.c...@kitware.com] > Sent: Thursday, June 24, 2010 15:22 > To: Convey, Christian J CIV NUWC NWPT > Cc: cmake@cmake.org > Subject: Re: [CMake] Ways of setting CTEST_BUILD_NAME > > cmake -DBUILDNAME=MyBuildName . && make && make test > > test does not depend on all so that it can just run > quickly... so you need the middle make in the above command > line if you actually want to build your stuff first. > > But why do you even need to set BUILDNAME for a "make test" > -- it only really applies when you're submitting a dashboard. > > You would do something like: > cmake -DBUILDNAME=MyBuildName && ctest -D Experimental > > ...to run an experimental dashboard including configure, > build and test stages... > > Does that make sense? smime.p7s Description: S/MIME cryptographic signature ___ 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] Ways of setting CTEST_BUILD_NAME
Suppose I want do just use "ctest" in a dead-simple manner: add a few lines to my CMakeLists.txt files, then run "cmake . && make test". In this scheme, what's the easiest way I can set CTEST_BUILD_NAME? Simply setting that variable in my CMakeLists.txt file doesn't *seem* to be effective. Thanks, Christian smime.p7s Description: S/MIME cryptographic signature ___ 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] CTEST_CHECKOUT_COMMAND vs. CTEST_UPDATE_COMMAND
Thanks. How does ctest know whether to employ "CVS_UPDATE_OPTIONS" vs. "SVN_UPDATE_OPTIONS" ? Also, the format you gave for "CVS_UPDATE_OPTIONS" looks like it has hte format of a line in the cache file. Is there some reason I'd need to force it into the cache, or is it okay for me to achieve the same effect using a SET(CVS_UPDATE_OPTIONS ...) call? - Christian > -Original Message- > From: Karthik Krishnan [mailto:karthik.krish...@kitware.com] > Sent: Thursday, June 24, 2010 11:51 > To: Convey, Christian J CIV NUWC NWPT > Cc: cmake@cmake.org > Subject: Re: [CMake] CTEST_CHECKOUT_COMMAND vs. CTEST_UPDATE_COMMAND > > You can specify the update options.. for instance : > > CVS_UPDATE_OPTIONS:STRING=-d -A -P > > similarly, there's > > SVN_UPDATE_OPTIONS [snip] smime.p7s Description: S/MIME cryptographic signature ___ 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] CTEST_CHECKOUT_COMMAND vs. CTEST_UPDATE_COMMAND
> I'm reading throught this page: > http://www.cmake.org/Wiki/CTest:Using_CTEST_and_CDASH_without_CMAKE > > It sounds like the variable "CTEST_CHECKOUT_COMMAND" is meant > to contain the ensure checkout command, including all arguments. Wow, I'm typing miserably lately. s/ensure/entire smime.p7s Description: S/MIME cryptographic signature ___ 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_CHECKOUT_COMMAND vs. CTEST_UPDATE_COMMAND
Could someone explain something to me about CTest's conventions? I'm reading throught this page: http://www.cmake.org/Wiki/CTest:Using_CTEST_and_CDASH_without_CMAKE It sounds like the variable "CTEST_CHECKOUT_COMMAND" is meant to contain the ensure checkout command, including all arguments. However, the "CTEST_UPDATE_COMMAND" is simply set to (for example) "svn". So if ctest is going to use this variable, it must be planning on supplying its own command-line arguments, such as "update" and (optionally) the path of the source code to be updated. So here's my question: Is there supposed to be a naming convention in CTest such that "..._COMMAND" is a complete command with all arguments? Or the basic program name without any arguments? Or is this just something for which no pattern exists? Thanks, Chritian smime.p7s Description: S/MIME cryptographic signature ___ 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] How specify revision for ctest_update(...) do check out?
I'm writing a (new style) ctest script. When I run it, I want it to check out the project's source code, as it was at the very beginning of the day (00:00). What's the right way to do this? (BTW, I'm using Subversion.) I would have assumed it's done by setting CTEST_NIGHTLY_START_TIME, but I'm not 100% what that variable is for. smime.p7s Description: S/MIME cryptographic signature ___ 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] ctest meant to be re-entrant?
> But, back to the original subject, if you can re-state what > your goal is a little bit, hopefully we can figure out a way > to get you there. Thanks very much. It's maybe more than can/should be done using "ctest". That is, some shell scripting might be in order as well... I have a CDash server set up. Every night, shortly after midnight, I want a bunch of build machines, running various operating systems, to build and test the software, and report their results to CDash. My project consists of two, somewhat-related bodies of source code: MOOS and IVP. Each has its own CMake-based build system. Each comes with a shell script that invokes "cmake" with some options, and then "make". The options supplied to cmake like CMAKE_BUILD_TYPE, CMAKE_CXX_FLAGS_RELEASE, and some application-specific CMake variables. If possible, I'd like to ensure that when ctest invokes cmake, the CMake variables mentioned above end up with the same values as they would have if the shell scripts mentioned above had been used to kick of cmake. This is a relatively low-priority requirement, but it would be nice. To date I've been ignoring MOOS with regards to CTest. I do have to build MOOS prior to building IVP, but I wanted to keep things simple for now and just focus on ctest'ing IVP. Since MOOS and IVP are in separate source trees and are built at separate times, I have no expectation that their building / testing results can end up in the same CDash dashboard. But it would be awfully nice if they did, because we really see them as two parts of the same product. It's only an accident of nature that they're not part of the very same CMake build tree. Furthermore, I want a shell command that I've designed to decide, for each build, what appears in CDash's "Build Name" column. I want this because "Linux-c++" doesn't sufficiently differentiate the various build platforms I'm using. If possible, I'd like the CDash report to include a mention of how the sourcecode checkout went. If the sourcecode checkout fails, I'd like CDash to show that, rather than just having no report from the client that had the problem. I want a fresh checkout of the source code each time I do this. Merely updating it isn't clean enough. Also, I'm using svn. I'd like to continue specifying my tests by having "ADD_TEST(...)" calls sprinkled throughout my project's CMakeLists.txt files. smime.p7s Description: S/MIME cryptographic signature ___ 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] ctest meant to be re-entrant?
> David is right; it's confusing because ctest can be used in > several different ways. I think it's actually much worse than > he says, because as far as I can tell, ctest can be used in > four completely different and mutually incompatible ways, > each with their own idiosyncrasies. To make things worse, two > of the ways are actually invoked with the same arguments! Thanks, actually I'm really glad you wrote all that [snipped] stuff. I was starting to think I was being uniquely moronic for having trouble figuring out ctest. You confirmed that it really is pretty complicated in its current incarnation. My self-respect is now partially restored. - Christian smime.p7s Description: S/MIME cryptographic signature ___ 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] ctest meant to be re-entrant?
> Sorry, that was embarrassing. Pretend I had said,
> "CTestTestFile.cmake" instead of "CTestConfig.cmake".
>
>
>
> Well, in that case CMake writes the CTestTestFile.cmake
> files whenever it configures a build tree. (So, from a ctest
> -S script, during the "ctest_configure(...)" call.) The ctest
> executable will read the CTestTestFile.cmake files when it
> needs to execute tests: when run from the command line to
> execute tests, or when processing a ctest_test(...) command
> in a -S script...
>
> So again: only one writer, at one well-defined time. I don't
> think there should be any problems with respect to the
> CTestTestFile.cmake files. The confusion arises perhaps
> because ctest is used as a "simple" test driver and also as a
> full configure/build/test/run-a-dashboard driver. The
> CTestTestFile.cmake files are used when it is acting as a
> simple test driver. You would write a script to be processed
> with -S, or run a -D Nightly or -D Experimental dashboard
> separately: that is not connected to the CTestTestFiles at all.
>
> I suppose you could probably contrive a case where an
> executing test actually re-configures the build tree that it
> is in, but I'd be surprised if that happens in practice. If
> shown to be problematic, and reported with reasonable steps
> to reproduce to the CMake bug tracker, we could add code to
> detect such pathological cases and fail with an error...
Thanks, that does help. Could you tell me if the following
approach constent with what you guys intended?
I want some parts of "CTestTestfile.cmake" to be automatically generated from
the CMakeLists.txt files in my source directory tree.
OTOH, I also want to supply some additional information ctest. For example,
'set(CTEST_BUILD_NAME "myBuildName")'.
So I do this:
1. Have a permanent (e.g., non-generated) file
"MyCTestScript.cmake" with the following content:
INCLUDE("CTestTestfile.cmake")
SET(CTEST_BUILD_NAME "myBuildName")
2. When I want to run tests, I use this command:
ctest -s MyCTestScript.cmake -D Nightly
- Christian
smime.p7s
Description: S/MIME cryptographic signature
___
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] ctest meant to be re-entrant?
Sorry, that was embarrassing. Pretend I had said, "CTestTestFile.cmake" instead of "CTestConfig.cmake". > CTestConfig.cmake should be a source file in your source > tree. Nothing should be writing it automatically. > > > > On Mon, Jun 21, 2010 at 11:21 AM, Convey, Christian J CIV > NUWC NWPT wrote: > > > I'm having trouble getting my mind around how CTest is > intended to be used. Could someone explain this to me? > > When you embed ctest-related statements into a > CMakeLists.txt file, and then run cmake on that file, you > produce a "CTestConfig.cmake" file. This file is eventually > executed by "ctest". > > But ctest also has the ability to run "cmake". In the > worst-case (in my mind) scenario, this ultimately leads to > "ctest" causing the rewriting of the very "CTestConfig.cmake" > file that it's presently executing. > > Is this intended? Or does it lie outside of the > intended ways of using ctest? > > > ___ > 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 > > > > smime.p7s Description: S/MIME cryptographic signature ___ 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 meant to be re-entrant?
I'm having trouble getting my mind around how CTest is intended to be used. Could someone explain this to me? When you embed ctest-related statements into a CMakeLists.txt file, and then run cmake on that file, you produce a "CTestConfig.cmake" file. This file is eventually executed by "ctest". But ctest also has the ability to run "cmake". In the worst-case (in my mind) scenario, this ultimately leads to "ctest" causing the rewriting of the very "CTestConfig.cmake" file that it's presently executing. Is this intended? Or does it lie outside of the intended ways of using ctest? smime.p7s Description: S/MIME cryptographic signature ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How set "Build Name" in CTest/CDash?
> The new-fashioned way is to set CTEST_BUILD_NAME in your > ctest -S script prior to ctest_configure, ctest_build and > ctest_submit... > set(CTEST_BUILD_NAME "myBuildName") Can I also do this in my CMakeLists.txt file? I guess I'm unclear on whether or not there aer some things that can *only* be done in the "ctest -S" script. > > Where were you reading the ctest manpage that talks about > setting CMAKE_SYSTEM and CMAKE_CXX_COMPILER variables?? What > version of ctest? That is completely incorrect, and if it's > in the official ctest documentation, we should fix that and > remove the incorrect information. Can you please reply and > tell me how you found this incorrect information...? I'm using CMake 2.8.0, which is what Ubuntu 9.10 supplies. smime.p7s Description: S/MIME cryptographic signature ___ 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] How set "Build Name" in CTest/CDash?
I'm using CTest to submit results to CDash. Can anyone tell me how to specify the text that shows up in CDash's "Build Name" column? The manpage for "ctest" says that I can set the CMAKS_SYSTEM and CMAKE_CXX_COMPILER variables, but I'm concerned that doing so may mess up my build. I have a Linux command-line command that yields the text I want to have show up in CDash. I just don't know how to safely get it there. smime.p7s Description: S/MIME cryptographic signature ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Problem getting out-of-source builds (yes I deleted CMakeCache.txt)
> > My goal is to have this work: > >> cd foo/build > >> cmake ../src/CMakeLists.txt > > that should be: cmake ../src Thanks. That did the trick. smime.p7s Description: S/MIME cryptographic signature ___ 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] Problem getting out-of-source builds (yes I deleted CMakeCache.txt)
Hi guys, Does anyone know why I might be having trouble getting out-of-source builds? I have this directory structure: foo /build /src /CMakeLists.txt /library_A /CMakeLists.txt /a.cpp ... /library_B /CMakeLists.txt /b.cpp ... My goal is to have this work: > cd foo/build > cmake ../src/CMakeLists.txt > make But my problems is that when I invoke 'cmake' as shown above, it places the build files under 'foo/src/', rather than under 'foo/build/'. I'm absolutely positive that the file 'foo/src/CMakeCache.txt' does not exist when I invoke cmake. I'm running CMake 2.6.2. Any ideas? Christian Convey Scientist Naval Undersea Warfare Centers Newport, Rhode Island, USA (phone) (401) 832-6824 (fax) (401) 832-4749 smime.p7s Description: S/MIME cryptographic signature ___ 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] Intel compiler on OS X? (solved)
It turns out that to compile c++ code, you use the "icpc" command to invoke the compiler, rather than the "icc" command. > -Original Message- > From: cmake-boun...@cmake.org > [mailto:cmake-boun...@cmake.org] On Behalf Of Convey, > Christian J CIV NUWC NWPT > Sent: Thursday, July 02, 2009 13:42 > To: cmake@cmake.org > Subject: [CMake] Intel compiler on OS X? > > Has anyone successfully used cmake (2.4.6) with the Intel > "icc" compiler (version 11.1) for OS X? > > When I run cmake I get an error: During cmake's "configure" > phase, cmake tells me that it couldn't successfully compile a > simple test program using the "icc" compiler. The specific > error issued is by the linker: > >Undefined symbols: > > "gxx_personality_v0", referenced from: > EH_frame0 in testCXXCompiler.cxx.o > >ld: symbol(s) not found > > > > Christian Convey > Scientist > Naval Undersea Warfare Centers > Newport, Rhode Island, USA > (p) (401) 832-6824 > (f) (401) 832-4749 > smime.p7s Description: S/MIME cryptographic signature ___ 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] Intel compiler on OS X?
Has anyone successfully used cmake (2.4.6) with the Intel "icc" compiler (version 11.1) for OS X? When I run cmake I get an error: During cmake's "configure" phase, cmake tells me that it couldn't successfully compile a simple test program using the "icc" compiler. The specific error issued is by the linker: Undefined symbols: "gxx_personality_v0", referenced from: EH_frame0 in testCXXCompiler.cxx.o ld: symbol(s) not found Christian Convey Scientist Naval Undersea Warfare Centers Newport, Rhode Island, USA (p) (401) 832-6824 (f) (401) 832-4749 smime.p7s Description: S/MIME cryptographic signature ___ 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] TARGET_LINK_LIBRARIES for library targets?
I've got three libraries, A, B, C. C uses symbols from B, and B uses symbols from A. When I build these libraries as static libraries (libA.a, libB.a, and libC.a), the linker is perfectly happy to produce libC.a even if I haven't told it about B. It seems that all that matters is, when I'm linking together some executable program that uses libC.a, I have to tell the linker about libB.a and (presumably) libA.a. When I tried building my libraries as shared objects, however, the linker seemed much fussier. When the linker was trying to produce libC.so, it got very upset about the unresolved symbols in libC.so's object code. To remedy this, I added this line: "TARGET_LINK_LIBRARIES(C, B)" and "TARGET_LINK_LIBRARIES(B, A)". But I'm not sure I understand all the ramifications of solving the problem this way. For example, does that mean that libC.so will export not only its own symbols, but also those provided by B and A? And would that answer change if I had build B and A as static libraries, while still building C as a shared object? Also, suppose I go back to building all my libraries as static libraries. Will there be any harm in having those TARGET_LINK_LIBRARIES statements still in my CMakeLists.txt files? And if I do leave them there, does this mean that I can get away with just writing this: TARGET_LINK_LIBRARIES(myApp C) rather than TARGET_LINK_LIBRARIES(myApp C B A) since CMake could (potentially) have enough information to realize that myApp has a transitive link-time dependency on B and A? Thanks, Christian ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Understanding why CMAKE_BUILD_TYPE cannot be set
>From the mail archives and personal experience, it looks to me like commands of the form: SET(CMAKE_BUILD_TYPE Debug) aren't effective. I don't think I fully understood the explanations of why, though. If it's ok to specify this variable on the cmake command line ( cmake -DCMAKE_BUILD_TYPE=Debug ) and via ccmake, why isn't it ok to specify it as a default by a SET command, like the one shown above? In my particular case, the users just about always want Debug builds, so that seems like a good default value for CMAKE_BUILD_TYPE. - Christian ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Recoverable build errors?
I've got a top-level CMake project with numerous executable and library sub-projects. I'd like to have CMake generate Makefiles such that if one of those subprojects fails the build process, the Makefile still attempts to build all other subprojects that aren't dependent on any of those which failed to build. Is this possible? Thanks, Christian ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
