Re: [CMake] cmake-2.8.12: generator expression error when linker flags have comma

2013-10-20 Thread Jed Brown
David, your reply failed to set In-Reply-To or References headers, and is thus not threaded with the conversation it purports to reply to, meaning that it skipped my inbox. If this was not intentional, you may want to check your mail client settings. David Cole writes: > One question about the

Re: [CMake] cmake-2.8.12: generator expression error when linker flags have comma

2013-10-20 Thread Jed Brown
Stephen Kelly writes: > Jed Brown wrote: > >> I just upgraded from cmake-2.8.11.2 to 2.8.12 and now get errors when a >> comma ',' appears in a linker flag. Test case below. Note that this is >> but one of many reasons for a comma to appear in linker flag

Re: [CMake] cmake-2.8.12: generator expression error when linker flags have comma

2013-10-20 Thread Jed Brown
Nick Hutchinson writes: > target_link_libraries() is supposed to work for linker flags as well: > > cmake version 2.8.12 > target_link_libraries >Link a target to given libraries. > > target_link_libraries( [item1 [item2 [...]]] >[[debug|optimize

[CMake] cmake-2.8.12: generator expression error when linker flags have comma

2013-10-19 Thread Jed Brown
I just upgraded from cmake-2.8.11.2 to 2.8.12 and now get errors when a comma ',' appears in a linker flag. Test case below. Note that this is but one of many reasons for a comma to appear in linker flags. https://gist.github.com/jedbrown/7062540 $ mkdir build && cd build $ cmake -DDEP_

Re: [CMake] how to write the following comand into cmake file.

2013-06-24 Thread Jed Brown
丁老师 writes: > thanks. but how to use it. how to install it into cmake. Like all Find*.cmake modules. It follows the usual conventions. > 在 2013-06-25 00:16:01,"Jed Brown" 写道: >>丁老师 writes: >> >>> I develop a parallel code with PETSc, it can sucessfully

Re: [CMake] Infinite loop with cmake-2.8.10.2

2012-12-28 Thread Jed Brown
On Fri, Dec 28, 2012 at 3:29 PM, Rolf Eike Beer wrote: > Changing the compiler usually will not work anyway. That's why we have > separate build trees: wipe the whole thing and start again. > Yes, I have a habit of runnning rm -rf * && cmake -DNEW_OPTIONS .. because changing cache variables (e

Re: [CMake] Infinite loop with cmake-2.8.10.2

2012-12-28 Thread Jed Brown
On Fri, Dec 28, 2012 at 2:52 PM, Rolf Eike Beer wrote: > Don't specify the compiler like this: > > CC=clang cmake . > I'm not looking for a work-around [*], I'm looking for the problem to be fixed so it stops blowing up in users' faces. The fact is that (a) -DCMAKE_C_COMPILER is an established a

[CMake] Infinite loop with cmake-2.8.10.2

2012-12-28 Thread Jed Brown
$ echo 'project (Test C)' > CMakeLists.txt $ cmake -DCMAKE_C_COMPILER:FILEPATH=clang . -- The C compiler identification is Clang 3.1.0 -- Check for working C compiler: /usr/bin/clang -- Check for working C compiler: /usr/bin/clang -- works -- Detecting C compiler ABI info -- Detecting C compiler A

[CMake] find_library with semantics of -Wl,-search_paths_first?

2011-11-03 Thread Jed Brown
The normal library search semantics on OS X are: Normally, the linker goes through each path in the search paths one at a time to find a dynamic version of the library. If none is found, it goes through each of those paths looking for a static version of the same library. http://developer.apple.c

Re: [CMake] Correct way to link with libstdc++ from non-C++ project?

2011-09-15 Thread Jed Brown
On Thu, Sep 15, 2011 at 18:57, Michael Wild wrote: > Just set the LINKER_LANGUAGE target property to CXX. This seems to be exclusive (single-valued). How can I specify that, for example, a target containing only C sources needs to be linked as though it also had both C++ and Fortran sources (be

[CMake] Correct way to link with libstdc++ from non-C++ project?

2011-09-15 Thread Jed Brown
Suppose project Foo depends on a library Bar that uses C++ internally, but was not properly linked, so foo would need to be linked with 1. $CC -shared -o libfoo.so *.o -lbar -lstdc++ or 2. $CXX -shared -o libfoo.so *.o -lbar Note that find_library (LIBSTDCXX NAMES stdc++) does not work becau

[CMake] Re-setting CMAKE_C_COMPILER on command line discards CMAKE_C_FLAGS

2011-08-25 Thread Jed Brown
$ cmake .. '-DCMAKE_C_COMPILER:FILEPATH=mpicc' '-DCMAKE_C_FLAGS:STRING= -Wall -Wwrite-strings -Wno-strict-aliasing -Wno-unknown-pragmas' [no problems] $ grep CMAKE_C_FLAGS:STRING CMakeCache.txt CMAKE_C_FLAGS:STRING= -Wall -Wwrite-strings -Wno-strict-aliasing -Wno-unknown-pragmas $ cmake .. [no prob

Re: [CMake] Enabling C99 in CMake

2011-06-23 Thread Jed Brown
On Thu, Jun 23, 2011 at 17:50, Michael Hertling wrote: > You need to use a C99 compiler for your project This is already a problem. C99 introduces new keywords (e.g. restrict) and removes implicit int. It is entirely possible for part of a project to include C89-conforming legacy code that is n

Re: [CMake] Gyp VS CMake

2011-02-19 Thread Jed Brown
On Sat, Feb 19, 2011 at 18:27, Michael Wild wrote: > Tup was already discussed on this list quite some time ago. Using > LD_PRELOAD to do those things makes my skin crawl. > Using an incorrect C preprocessor and needing to write a dependency generator for each language/dialect makes my skin craw

Re: [CMake] Gyp VS CMake

2011-02-19 Thread Jed Brown
On Fri, Feb 18, 2011 at 17:16, Michael Wild wrote: > Well, cl.exe for one doesn't do this trick. This means, you'll have to > put it in your build system, and once you've done that, why should you > use the compiler then? Especially, since you'll want to be consistent > across platforms. > You c

Re: [CMake] Gyp VS CMake

2011-02-19 Thread Jed Brown
On Fri, Feb 18, 2011 at 20:42, Troy Straszheim wrote: > I'm actually *generating* CMakeLists.txt files with python I do this too, partly to work around the language and partly because we have a configuration system that we want cmake builds to be consistent with (it handles batch environments be

Re: [CMake] How to specify $1 for compiler?

2011-02-08 Thread Jed Brown
On Mon, Feb 7, 2011 at 23:35, Jed Brown wrote: > On Fri, Feb 4, 2011 at 01:31, Michael Hertling wrote: > >> With a Makefile generator, you might use a RULE_LAUNCH_COMPILE property: >> >> SET_TARGET_PROPERTIES( PROPERTIES RULE_LAUNCH_COMPILE "win32fe") >>

Re: [CMake] How to specify $1 for compiler?

2011-02-07 Thread Jed Brown
On Thu, Feb 3, 2011 at 14:42, Michael Wild wrote: > > That depends on the quoting you use. > The variable type is FILEPATH, spaces are always escaped by CMake (it's not up to me). ___ Powered by www.kitware.com Visit other Kitware open-source projects

Re: [CMake] How to specify $1 for compiler?

2011-02-07 Thread Jed Brown
On Fri, Feb 4, 2011 at 01:31, Michael Hertling wrote: > With a Makefile generator, you might use a RULE_LAUNCH_COMPILE property: > > SET_TARGET_PROPERTIES( PROPERTIES RULE_LAUNCH_COMPILE "win32fe") > Thanks for these suggestions. I went with this one, but I'll try the other if someone complains

Re: [CMake] How to specify $1 for compiler?

2011-02-03 Thread Jed Brown
On Thu, Feb 3, 2011 at 16:33, Michael Wild wrote: > CMAKE_Fortran_COMPILER="/path/to/win32fe -f90 -with -options" > Doesn't work because that whole thing becomes $0, which does not exist on the file system. ___ Powered by www.kitware.com Visit other K

[CMake] How to specify $1 for compiler?

2011-02-03 Thread Jed Brown
I need to build a compilation command of the form win32fe f90 -with -options -and source.f -o path/to/source.f.o but setting CMAKE_Fortran_COMILER=/path/to/win32fe and CMAKE_Fortran_FLAGS="f90 -with -options" does not work because CMake places other options in between: win32fe -o path/to/sou

[CMake] gfortran and -header_pad_max_install_names on OS X

2010-12-15 Thread Jed Brown
It appears that CMake is adding this automatically to the link line, but the user reporting this issue is using a normal gfortran which does not recognize this option. How should I get CMake to link properly with this non-Apple compiler (I think it just needs to leave out that option)? ___

[CMake] cmake-gui has very slow path completion in directories with many files

2010-10-24 Thread Jed Brown
Entering a path in cmake-gui causes a long stall when the directory has many files. For example, /usr/bin and /usr/lib have about 4000 files, and when typing a path to /usr/lib/libfoo.so, the gui locks up completely for 15 to 20 seconds. This is not a file system issue since listing the directory

Re: [CMake] linking main Fortran and C++

2010-10-21 Thread Jed Brown
On Thu, Oct 21, 2010 at 16:52, M. Scot Breitenfeld wrote: >  It was part of a section detecting if mpi is present, if it is then it uses > the mpi** compiler wrappers instead: > > IF ( MPI_FOUND ) >  SET (CMAKE_Fortran_COMPILER  mpif90) >  SET (CMAKE_CC_COMPILER  mpicc) This is a typo, should be

Re: [CMake] *.c compiled with C compiler after clearing CMAKE_C_SOURCE_FILE_EXTENSIONS

2010-10-14 Thread Jed Brown
On Wed, Oct 13, 2010 at 22:21, Alexander Neundorf wrote: > CMAKE__SOURCE_FILE_EXTENSIONS is used quite early in the > enable-language process, i.e. when the > CMakeFiles/CMakeCompiler.cmake file is generated. > If the variable is changed after that happened, it doesn't have an effect > anymore. T

Re: [CMake] *.c compiled with C compiler after clearing CMAKE_C_SOURCE_FILE_EXTENSIONS

2010-10-12 Thread Jed Brown
On Tue, Oct 12, 2010 at 15:33, Michael Wild wrote: > set(SRCS src1.c src2.c src3.c) > set_source_files_properties(${SRCS} PROPERTIES LANGUAGE CXX) > add_executable(strange_beast ${SRCS}) > I can do that, but what's the point of the extension-based mapping if you have to set properties by file?

[CMake] *.c compiled with C compiler after clearing CMAKE_C_SOURCE_FILE_EXTENSIONS

2010-10-12 Thread Jed Brown
I realize this may look silly, but after list (REMOVE_ITEM CMAKE_C_SOURCE_FILE_EXTENSIONS c) list (APPEND CMAKE_CXX_SOURCE_FILE_EXTENSIONS c) source files matching *.c are still compiled with the C compiler (not C++). Is there a way to get *.c compiled with the C++ compiler? (cmake-2.8.2)

Re: [CMake] makefile to CMakeLists.txt, possible?

2010-09-02 Thread Jed Brown
On Thu, Sep 2, 2010 at 10:08, Michael Wild wrote: > Ever timed "gcc -M" which is the usual approach to dependency-generation of > hand-crafted Makefiles? THAT is slow. ;-) It's also correct, which requires preprocessing all the headers. gcc -MMD will do the same as a side-effect of the build so

Re: [CMake] CMake without C/C++ compiler check.

2010-08-30 Thread Jed Brown
On Mon, 30 Aug 2010 13:11:46 +0200, Giraudon Cyril wrote: > Hello, > > I'd like to use CMake to build a fortran project (ifort) and > on my win64 machine, I have no C/C++ compiler. > > CMake seems to check always C/C++ compilers and this makes errors. > > So I'd like to know if there is any

Re: [CMake] several questions about cmake

2010-08-27 Thread Jed Brown
Quoth Stroustrup (http://www2.research.att.com/~bs/bs_faq2.html#void-main): The definition void main() { /* ... */ } is not and never has been C++, nor has it even been C. See the ISO C++ standard 3.6.1[2] or the ISO C standard 5.1.2.2.1. A conforming implementation accepts

Re: [CMake] several questions about cmake

2010-08-27 Thread Jed Brown
On Fri, 27 Aug 2010 08:10:49 -0700, Mark Roden wrote: > And it turns out that it is valid C++ to have > void main() > > because it's valid C. > > Source: > http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/legality-of-void-main.html You seem to have misread the link (which appears to fal

Re: [CMake] Fortran 90 module output directories, dependency analysis

2010-06-01 Thread Jed Brown
On Tue, 01 Jun 2010 13:48:21 -0400, Brad King wrote: > You can delete the object file the provides the module. That doesn't seem to be enough if there is another target that depends on the module. E.g. if I delete petscmat.mod and CMakeFiles/.../petscmatmod.F.o, then run 'make all', I get an err

Re: [CMake] Fortran 90 module output directories, dependency analysis

2010-06-01 Thread Jed Brown
On Tue, 01 Jun 2010 13:02:29 -0400, Brad King wrote: > Jed Brown wrote: > > Is there a way to specify where generated *.mod files will be placed? > > Something analogous to CMAKE_LIBRARY_OUTPUT_DIRECTORY? > > http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:For

Re: [CMake] Fortran 90 module output directories, dependency analysis

2010-06-01 Thread Jed Brown
On Tue, 1 Jun 2010 08:43:43 -0600, "Kelly Thompson" wrote: > This can be done using a Fortran compile option. For gfortran, add the > option "-M" to CMAKE_Fortran_FLAGS. Sure, however 1. One should use -J instead because (since 4.0), "-M is deprecated to avoid conflicts with existing GCC o

[CMake] Fortran 90 module output directories, dependency analysis

2010-05-31 Thread Jed Brown
Is there a way to specify where generated *.mod files will be placed? Something analogous to CMAKE_LIBRARY_OUTPUT_DIRECTORY? Also, I notice that if I delete a module file, the build fails (unlike everything else where it will be properly regenerated). This is with a plain Makefile build, cmake-2.

Re: [CMake] Effort to create a new generator (tup)

2010-05-06 Thread Jed Brown
On Thu, 6 May 2010 18:16:14 +0200, Michael Wild wrote: > > Another issue: How would one automatically rerun CMake when one of the > input files to CMake changes? Of course, the build would then have to > continue with the potentially modified Tupfile's... Rebuilding with modified Tupfiles is not

Re: [CMake] Effort to create a new generator (tup)

2010-05-06 Thread Jed Brown
On Thu, 6 May 2010 17:41:45 +0200, Michael Wild wrote: > > On 6. May, 2010, at 17:37 , Jed Brown wrote: > > > On Thu, 6 May 2010 17:32:28 +0200, Michael Wild wrote: > >> Ugh, yes. So this should be (does tup accept absolute source file paths?) > >> > >&

Re: [CMake] Effort to create a new generator (tup)

2010-05-06 Thread Jed Brown
On Thu, 6 May 2010 17:32:28 +0200, Michael Wild wrote: > Ugh, yes. So this should be (does tup accept absolute source file paths?) > > /path/to/a.f90 |> gfortran -c -o %o %f |> %B.o %B.mod No problem on the source paths, but I think this should be /path/to/a.f90 |> gfortran -c -o %B.o %f |> %

Re: [CMake] Effort to create a new generator (tup)

2010-05-06 Thread Jed Brown
On Thu, 6 May 2010 16:42:13 +0200, Michael Wild wrote: > Looks like the Fortran 90 issue can be solved with "order-only" inputs: > > a.f90 |> gfortran -c -o %o %f |> %f.o This line also produces a.mod. > b.f90 | a.f90 |> gfortran -c -o %o %f |> %f.o Maybe you meant b.f90 | a.mod |> gfortran

Re: [CMake] Effort to create a new generator (tup)

2010-05-06 Thread Jed Brown
On Thu, 6 May 2010 16:36:14 +0200, Michael Wild wrote: > Looking at the manpage, it seems that CMake will need a Tupfile in > every directory that is to contain object files: Tup would either need to add support for "make install" or CMake would need a different way of doing installs. Jed __

Re: [CMake] No Native 64-Bit CMake Binaries?

2010-05-06 Thread Jed Brown
On Thu, 06 May 2010 09:49:37 -0400, Bill Hoffman wrote: > I still don't see the desire for 64 bit when 32 bit works... :) The 32-bit version either needs to be statically linked, or requires compatibility libraries. Google Earth and Skype is currently the only things on my Linux machine that r

Re: [CMake] Effort to create a new generator (tup)

2010-05-06 Thread Jed Brown
On Thu, 06 May 2010 09:10:51 -0400, Bill Hoffman wrote: > OK, so aside from the fortran depend stuff being moved to generate time. > I think the remaining questions are these: > > How would a large tup system be organized? Would there be a tup file for > each target? Would there be one huge t

Re: [CMake] Effort to create a new generator (tup)

2010-05-06 Thread Jed Brown
On Thu, 06 May 2010 08:28:34 -0400, Bill Hoffman wrote: > The problem with fortran 90, is that you have to find out the depends to > figure out the order in which files are built. It has a system where > "include like" files are generated by the compiler. So, if you have: > > a.f90 -> produ

Re: [CMake] Effort to create a new generator (tup)

2010-05-05 Thread Jed Brown
On Wed, 05 May 2010 16:08:14 -0400, Bill Hoffman wrote: > Not sure yet, perhaps none of it. It would have to build custom > commands and targets. Basically, support for code generators like > swig/moc/lex/yacc. I guess the auto-depend stuff in tup would work for > C/C++, but the Fortran 90

Re: [CMake] Please support FindLAPACK/FindBLAS for C/C++-only projects

2010-01-22 Thread Jed Brown
On Fri, 22 Jan 2010 15:43:42 -0500, Bill Hoffman wrote: > It should just work as the clapack has the correct package export stuff > in its cmake files. Cool, but I don't see the point. Most people want to link to the vendor's implementation so they still need a robust Find* module. Jed __

Re: [CMake] Please support FindLAPACK/FindBLAS for C/C++-only projects

2010-01-22 Thread Jed Brown
On Fri, 22 Jan 2010 10:30:28 +0100, Michael Wild wrote: > This is already in CMake: FortranCInterface.cmake Sort of, this requires Fortran to be enabled. This thread started with the desire to use BLAS/Lapack *without* enabling Fortran. Jed ___ Powere

Re: [CMake] Checking function or symbol in namespace

2010-01-22 Thread Jed Brown
On Fri, 22 Jan 2010 10:24:30 +0100, "Marcel Loose" wrote: > Partly true. > If the preprocessor symbol provides a generic name for a function, which > may have different names on different platforms, it will still work. > > For example. > > # define basename __xdg_basename No. It will *not* wo

Re: [CMake] Please support FindLAPACK/FindBLAS for C/C++-only projects

2010-01-22 Thread Jed Brown
On Fri, 22 Jan 2010 10:05:19 +0100, Arjen Markus wrote: > This would indeed not work on systems that do not provide an nm-like > utility, but there is an system-independent way to do this: Seems like this falls under "testing a number of common choices". The code to iterate through the choices

Re: [CMake] Please support FindLAPACK/FindBLAS for C/C++-only projects

2010-01-21 Thread Jed Brown
On Thu, 21 Jan 2010 11:27:19 -0600, Mark Moll wrote: > Wouldn’t it be possible to use “nm” to detect the Fortran name mangling? For > example: Sure, provided you have nm. Jed ___ Powered by www.kitware.com Visit other Kitware open-source projects at

Re: [CMake] Checking function or symbol in namespace

2010-01-21 Thread Jed Brown
On Thu, 21 Jan 2010 16:55:20 +, Mateusz Loskot wrote: > Yes, though I'd annoyingly keep my side that CXX variants of the macros > would be useful and make C vs C++ separation more clear to user. The problem is that the interface for the C++ variant *cannot* look like check_function_exists, be

Re: [CMake] Please support FindLAPACK/FindBLAS for C/C++-only projects

2010-01-21 Thread Jed Brown
On Thu, 21 Jan 2010 09:17:22 -0600, Mark Moll wrote: > You *can* use the Fortran BLAS/LAPACK libraries with C/C++ code. Yes, this is actually very common, but check_fortran_function_exists works by trying to link an actual Fortran program. When calling from C, you have to know how Fortran names

Re: [CMake] Checking function or symbol in namespace

2010-01-21 Thread Jed Brown
On Thu, 21 Jan 2010 17:03:27 +0100, Michael Wild wrote: > But both of them just do a try_compile. I don't see where the > name-mangling comes in there... If the user wants to check for a > template, he has to instantiate the template, > e.g. check_cxx_function_exists("std::copy std::string::iterat

Re: [CMake] Checking function or symbol in namespace

2010-01-21 Thread Jed Brown
On Thu, 21 Jan 2010 15:44:43 +, Mateusz Loskot wrote: > Why it can not work, actually? C++ does name mangling so it's difficult to determine what the symbol actually is (you have to know about various classes and templates that may be in scope), therefore the interface would look a bit differ

Re: [CMake] intercomponent link dependencies?

2010-01-17 Thread Jed Brown
On Fri, 15 Jan 2010 18:59:45 +0100, Alexander Neundorf wrote: > In general, yes. Neat, I'd never heard of this being recommended. > It's just that this feature is still relatively new (2 years now), and I > think > no existing Find-module has been converted. :-/ It looks like it would be we

Re: [CMake] intercomponent link dependencies?

2010-01-13 Thread Jed Brown
On Wed, 13 Jan 2010 07:04:46 -0600, Ryan Pavlik wrote: > You could use the CleanLibraryList module I posted a few emails ago: > just make a list that contains all the libraries you are going to link > your target against, and then just run clean_library_list on it before > doing so. The troubl

Re: [CMake] intercomponent link dependencies?

2010-01-13 Thread Jed Brown
On Wed, 13 Jan 2010 13:51:57 +0100, Nico Schlömer wrote: > > Overlinking is actually only an issue for dynamic libraries. So as > > long as you're absolutely sure that you only have static libraries, > > you're fine. > > Oh, I was thinking it is *unclean* to have a link line like Overlinking is

Re: [CMake] intercomponent link dependencies?

2010-01-08 Thread Jed Brown
On Thu, 7 Jan 2010 19:24:19 -0600, Ryan Pavlik wrote: > So then actually should we all be doing imported targets in our find modules > then? Many/most Find* modules don't work with static libraries. Jed ___ Powered by www.kitware.com Visit other Kitwa

Re: [CMake] intercomponent link dependencies?

2010-01-07 Thread Jed Brown
On Thu, 07 Jan 2010 15:54:33 -0600, Ryan Pavlik wrote: > If you use the _LIBRARIES variable, you don't need to even mess around > with the imported targets thing Dumping recursive dependencies in *_LIBRARIES causes overlinking, they should only be there when linking statically. Jed _

Re: [CMake] target_link_libraries: prefer static to dynamic

2009-12-30 Thread Jed Brown
On Wed, 30 Dec 2009 17:51:29 +0100, Michael Wild wrote: > > On 30. Dec, 2009, at 17:32 , Jed Brown wrote: > > > On Mon, 28 Dec 2009 12:29:05 +0100, Pau Garcia i Quiles > > wrote: > >> I'm using CMake 2.8.0 on Linux. Yes, Michael is right: I want it to >

Re: [CMake] target_link_libraries: prefer static to dynamic

2009-12-30 Thread Jed Brown
On Mon, 28 Dec 2009 12:29:05 +0100, Pau Garcia i Quiles wrote: > I'm using CMake 2.8.0 on Linux. Yes, Michael is right: I want it to > happen automagically. That was the whole point of this thread :-) I would argue that FindXXX.cmake is the wrong place for the decision to be made since I may wan

Re: [CMake] third party library dependencies

2009-12-19 Thread Jed Brown
On Fri, 18 Dec 2009 14:45:51 -0500, Roman Shtylman wrote: > In my setup I have statically linked libraries, thus the library > dependencies are not automatically pulled in. I suppose I can do some > things with ldd to determine which libraries are needed. Yes, but ldd will only help if your syste

Re: [CMake] third party library dependencies

2009-12-18 Thread Jed Brown
On Fri, 18 Dec 2009 10:19:05 +0100, "Marcel Loose" wrote: > Hi Roman, > > Not in a portable way. I'm not too familiar with Windows, but on Linux > you can do this when libA is a shared library that has its dependency on > libB linked in (e.g. ldd libA.so will tell you this). When linking in > sta

Re: [CMake] Source file symlinks on out-of-source builds

2009-12-04 Thread Jed Brown
On Thu, 03 Dec 2009 18:17:21 -0200, Rodolfo Schulz de Lima wrote: > How does emacs know all the project files? Or it is only looking > backwards on the include list (this would only find header files)? M-x visit-tags-table I have a cmake command to generate tags in the *source* directory, I run

Re: [CMake] Source file symlinks on out-of-source builds

2009-12-03 Thread Jed Brown
On Thu, 03 Dec 2009 16:59:01 -0200, Rodolfo Schulz de Lima wrote: > Hi Jed, I know about ctags and the like, but I'm don't use them (but I > should). But these tools cover only a part of the problem. If you want > to go to another file and there's no useful context around the current > file posit

Re: [CMake] Source file symlinks on out-of-source builds

2009-12-03 Thread Jed Brown
On Thu, 03 Dec 2009 16:26:19 -0200, Rodolfo Schulz de Lima wrote: > About emacs/vi, they can locate the source file only if we're going > though an error list, as gcc spits out the path to the source files > involved. But if you want to load another file, you must do it yourself, > which can be i

Re: [CMake] functions as first class objects

2009-11-19 Thread Jed Brown
Michael Wild wrote: > Although this is OT, I have to say that this is not true. C++ is still > statically typed. Yes, it is statically typed, but symbols can have different definitions in different scopes. Overloaded functions are actually different, but template instances are written into every

Re: [CMake] functions as first class objects

2009-11-19 Thread Jed Brown
Michael Wild wrote: > > On 19. Nov, 2009, at 15:06 , Jed Brown wrote: > >> Michael Wild wrote: >> >>> Not sure I'd like that... Instead of being more expressive, I think this >>> would be very confusing. >> >> This is not a some magic bea

Re: [CMake] functions as first class objects

2009-11-19 Thread Jed Brown
Michael Wild wrote: > Not sure I'd like that... Instead of being more expressive, I think this > would be very confusing. This is not a some magic beast coming out of functional languages. In fact, it's pretty hard to find a language that can't do this sort of thing, even older Fortrans let you

Re: [CMake] Finding the correct Python framework with cmake

2009-11-11 Thread Jed Brown
Mark Moll wrote: > Add "-F /opt/local/Library/Frameworks" to your compilation flags or > add this line to your .bash_profile: > > export DYLD_FRAMEWORK_PATH=/opt/local/Library/Frameworks It seems to me that the only acceptable solution is that FindPythonInterp.cmake and FindPythonLibs.cmake consu

Re: [CMake] Bug#553151: CMake 2.8.0 RC 4 ready for testing!

2009-10-29 Thread Jed Brown
Mathieu Malaterre wrote: > On Thu, Oct 29, 2009 at 7:16 PM, Alexander Neundorf > wrote: >> On Thursday 29 October 2009, Mathieu Malaterre wrote: >> ... >>> Done: >>> http://cmake.org/Bug/view.php?id=9793 >>> >>> Bug report include the test I used. Unfortunately find_package caches >>> results, so

Re: [CMake] Suggesting to FindQT4.cmake where to find QT4

2009-05-29 Thread Jed Brown
Adolfo Rodríguez wrote: > On Fri, May 29, 2009 at 5:48 AM, Clinton Stimpson wrote: >> I think what is being asked here is a good idea. There is already >> the CMAKE_PREFIX_PATH which gives find_package(Qt4) a prefix to work >> from. If I set it to one of my other Qt4, directories, it finds that

Re: [CMake] Suggesting to FindQT4.cmake where to find QT4

2009-05-28 Thread Jed Brown
Alexander Neundorf wrote: > On Monday 25 May 2009, Jed Brown wrote: >> Bill Hoffman wrote: >>> You can also set QMake on the cmake command line as well: >>> >>> cmake -DQT_QMAKE_EXECUTABLE=/path/to/qmake ../source >> Yeah, I'm much less concerned with

Re: [CMake] Suggesting to FindQT4.cmake where to find QT4

2009-05-25 Thread Jed Brown
Andreas Pakulat wrote: > On 25.05.09 23:17:55, Jed Brown wrote: > As soon as people start installing differing versions of the same > software into the same prefix they've already screwed up anyway. Thats > not supported by any software I use on a daily basis (even KDE3 and K

Re: [CMake] Suggesting to FindQT4.cmake where to find QT4

2009-05-25 Thread Jed Brown
Bill Hoffman wrote: > You can also set QMake on the cmake command line as well: > > cmake -DQT_QMAKE_EXECUTABLE=/path/to/qmake ../source Yeah, I'm much less concerned with this particular case as with the philosophy that the correct way to select installations is by modifying PATH. Frustratingl

Re: [CMake] Suggesting to FindQT4.cmake where to find QT4

2009-05-25 Thread Jed Brown
David Thompson wrote: >>> Have you ever tried setting the PATH? It is actually quite easy and does >>> not involve "great contortions". >>> >>> All I do is execute >>> >>> PATH='/home/software/qtsdk-2009.02/qt/bin:'$PATH >>> >>> and from then on, cmake uses the version of Qt4 that I downloaded and

Re: [CMake] Suggesting to FindQT4.cmake where to find QT4

2009-05-25 Thread Jed Brown
Alan W. Irwin wrote: > Have you ever tried setting the PATH? It is actually quite easy and does > not involve "great contortions". > > All I do is execute > > PATH='/home/software/qtsdk-2009.02/qt/bin:'$PATH > > and from then on, cmake uses the version of Qt4 that I downloaded and > installed

Re: [CMake] Suggesting to FindQT4.cmake where to find QT4

2009-05-25 Thread Jed Brown
Jed Brown wrote: > Andreas Pakulat wrote: > >> Can you please elaborate, I have no idea what a/b or foo/bar refer to in >> this example. However qmake knows exactly where the headers and libs >> (and data) for the Qt its supposed to be used with are. So having the >

Re: [CMake] Suggesting to FindQT4.cmake where to find QT4

2009-05-25 Thread Jed Brown
Andreas Pakulat wrote: > Can you please elaborate, I have no idea what a/b or foo/bar refer to in > this example. However qmake knows exactly where the headers and libs > (and data) for the Qt its supposed to be used with are. So having the > right qmake first in your PATH is the right thing to se

Re: [CMake] Suggesting to FindQT4.cmake where to find QT4

2009-05-25 Thread Jed Brown
Alan W. Irwin wrote: > My experience is that you can cleanly distinguish between various Qt4 > versions by simply putting qmake for the version you want first on > your PATH. Do you seriously consider this a solution, or just a hack that works for you? It breaks as soon as you have two packages

Re: [CMake] Static linking and find_library

2009-05-08 Thread Jed Brown
Denis Scherbakov wrote: > In general, linking statically is a very bad idea. Not always though. There are many reasons for linking statically including distributing an app that uses a small part of a library without requiring users to have the whole thing, running on compute nodes that do not su

[CMake] Proposal: variant of create_test_sourcelist using sym- or hard-links

2009-04-30 Thread Jed Brown
For executables that are strictly tests (i.e. will never be invoked directly by the user) there is no problem with calling the executable as CommonTests testname args ... because the user/developer never needs to see this. When the executable is also a utility or will be run manually for other

Re: [CMake] lack of operator for easy string concatenation

2009-04-08 Thread Jed Brown
On Wed 2009-04-08 20:50, Piotr Dobrogost wrote: > John Drescher wrote: > > > On Wed, Apr 8, 2009 at 2:27 PM, Piotr Dobrogost > > wrote: > >> Hi > >> > >> Am I missing something or there is no operator for easy string > >> concatenation in cmake? > > > > I guess its a matter of preference. I pref

Re: [CMake] CMake could really use a debugger...

2009-04-02 Thread Jed Brown
On Thu 2009-04-02 13:17, Robert Dailey wrote: > It would be great to see CMake provide some more debug-related commands later. > Perhaps CMake could even implement its own prompt. It would be extremely useful to be able to set watchpoints and breakpoints. Basically the GDB commands break, watch,

Re: [CMake] ccmake gets all squirrelly over which C++ compiler to use.

2009-03-03 Thread Jed Brown
On Tue 2009-03-03 09:20, kent williams wrote: > Lather, Rinse, Repeat. After 2 or 3 go-arounds, CCMake is happy and > lets you generate your build files. This and the fact that most modules aren't written to handle multiple passes (for instance, if the wrong version is found on the first pass, the

Re: [CMake] Avoiding a relink

2009-02-27 Thread Jed Brown
On Fri 2009-02-27 20:26, Jed Brown wrote: > On Fri 2009-02-27 11:09, Bill O'Hara wrote: > > Lets say I have a CMakeLists.txt like this: > > > > add_library(foo STATIC foo.c bar.c) > > add_executable(test test.c) > > target_link_libraries(test foo) > >

Re: [CMake] Avoiding a relink

2009-02-27 Thread Jed Brown
On Fri 2009-02-27 11:09, Bill O'Hara wrote: > Lets say I have a CMakeLists.txt like this: > > add_library(foo STATIC foo.c bar.c) > add_executable(test test.c) > target_link_libraries(test foo) > > where test.c uses only functions defined in foo.c but not bar.c (assume some > other target will us

[CMake] Linking dependent libraries

2009-02-25 Thread Jed Brown
I found a bug in my FindGSL.cmake module and I'm having trouble finding an acceptable way to resolve it. Some installations of GSL (GNU Scientific Library) do not have libgsl.so linked against libgslcblas.so in which case our project should link with -lgsl -lgslcblas even though we only call funct

Re: [CMake] History and ideas behind FindMPI.cmake?

2009-01-12 Thread Jed Brown
On Mon, Jan 12, 2009 at 13:02, Bartlett, Roscoe A wrote: > Does anyone else have similar frustrations with FindMPI.cmake and would like > to see a new implementation as described above? How many CMake projects > have a serious MPI component that use FindMPI.cmake? I make do with the current impl

Re: [CMake] uninstall target & libraries

2008-11-25 Thread Jed Brown
On Tue 2008-11-25 16:27, Pablo Yanez Trujillo wrote: > the file names should be: libmylib.so and libmylib.a instead of > libmylib-shared.so and limylib-static.a? Also an FAQ http://www.cmake.org/Wiki/CMake_FAQ#How_do_I_make_my_shared_and_static_libraries_have_the_same_root_name.2C_but_different_

Re: [CMake] What does `cross-platform' mean?

2008-11-10 Thread Jed Brown
On Mon 2008-11-10 08:23, Bill Hoffman wrote: > So, each find module should have a consistently named variable that can > control the prefix for finding the module. For example, FindFoo.cmake, > would have FOO_DIR. If that environment variable is set and CMake can > not find it, it is an err

Re: [CMake] What does `cross-platform' mean?

2008-11-10 Thread Jed Brown
Thanks Michael, it's good to hear I'm not alone :-) On Sun 2008-11-09 20:16, Michael Jackson wrote: > So basically if you don't have the HDF5_INSTALL env variable set then my > module probably will not find it, which is good in that instead of > getting a wrong version of HDF5 you just don't ge

Re: [CMake] What does `cross-platform' mean?

2008-11-10 Thread Jed Brown
On Sun 2008-11-09 17:55, Bill Hoffman wrote: > OK, so you have version of libraries that are not in default locations, > how is any build system supposed to find stuff like this? Of course not automatically, but with minimal hinting. Ideally the user runs CMake and sees one visible cache entry

Re: [CMake] What does `cross-platform' mean?

2008-11-09 Thread Jed Brown
On Fri 2008-11-07 10:47, Bill Hoffman wrote: > So, currently CMake assumes that the environment you are working from is > correctly configured. I think adding CMakeModule would go beyond the > scope of what CMake should be doing. Just like you have to have a > working compiler in your path

Re: [CMake] What does `cross-platform' mean?

2008-11-07 Thread Jed Brown
On Fri 2008-11-07 12:57, Eric Noulard wrote: > 2008/11/7 Jed Brown <[EMAIL PROTECTED]>: [snip] > > It's much clearer if CMake never intends to support this usage. > > I think this was not designed for that, just as CMake 2.4 was not > designed for cross-compiling.

Re: [CMake] Recursive dependencies and static libraries

2008-11-07 Thread Jed Brown
On Fri 2008-11-07 12:43, Hendrik Sattler wrote: > Jed Brown schrieb: > >>>> The FindPkgConfig.cmake module looks broken too, it assumes that > >>>> > >>>> -L/A -la -L/B -lb > >>>> > >>>> is equivalent to > &g

Re: [CMake] What does `cross-platform' mean?

2008-11-07 Thread Jed Brown
On Fri 2008-11-07 11:32, Mike Arthur wrote: > I've used CMake on Debian, Red Hat, Fedora, Slackware, Gentoo, Windows XP, > Windows Vista, OSX 10.4, OSX 10.5 and custom-rolled Linux distributions. I've > used it across four architectures and four compilers. I've introduced it into > two companies

Re: [CMake] What does `cross-platform' mean?

2008-11-07 Thread Jed Brown
On Fri 2008-11-07 11:44, Eric Noulard wrote: > 2008/11/7 Jed Brown <[EMAIL PROTECTED]>: > > Are such environments not a goal of CMake? > > As far as I know there is not so much systems where the simultaneous > installation of different version of the same software is c

Re: [CMake] What does `cross-platform' mean?

2008-11-07 Thread Jed Brown
On Fri 2008-11-07 11:28, Andreas Pakulat wrote: > If you run into such problems then open bugreports. Many of the > FindXXX.cmake modules have been contributed and most people out there don't > have a cluster of different types of machines with different installations > of the software at hand. Its

[CMake] What does `cross-platform' mean?

2008-11-07 Thread Jed Brown
I find that CMake works well when there is only one version of installed software, and shared libraries are used. When there are multiple ABI-incompatible versions of libraries or no shared libraries, many modules are broken. They will systematically find incompatible libraries even with optimal

Re: [CMake] Recursive dependencies and static libraries

2008-11-07 Thread Jed Brown
On Thu 2008-11-06 21:03, Jed Brown wrote: > On Thu 2008-11-06 13:18, Bill Hoffman wrote: > > Jed Brown wrote: > > > >> The FindPkgConfig.cmake module looks broken too, it assumes that > >> > >> -L/A -la -L/B -lb > >> > >> is equivalent

  1   2   >