Nick Hutchinson nshutchin...@gmail.com 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(target [item1 [item2 [...]]]
Stephen Kelly steve...@gmail.com 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 flags.
I've pushed a fix
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 dlrd...@aol.com writes:
One
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
丁老师 ztdepya...@163.com 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 five...@gmail.com 写道：
丁老师 ztdepya...@163.com writes:
I develop a parallel code with PETSc, it can
$ 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
On Fri, Dec 28, 2012 at 2:52 PM, Rolf Eike Beer e...@sf-mail.de 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
On Fri, Dec 28, 2012 at 3:29 PM, Rolf Eike Beer e...@sf-mail.de 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
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.
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
On Thu, Sep 15, 2011 at 18:57, Michael Wild them...@gmail.com 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
$ 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
On Thu, Jun 23, 2011 at 17:50, Michael Hertling mhertl...@online.de wrote:
You need to use a C99 compiler for your project
This is already a problem. C99 introduces new keywords (e.g. restrict) and
removes implicit int. It is entirely possible for part of a project to
include C89-conforming
On Fri, Feb 18, 2011 at 20:42, Troy Straszheim
straszh...@willowgarage.comwrote:
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
On Fri, Feb 18, 2011 at 17:16, Michael Wild them...@gmail.com 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
On Sat, Feb 19, 2011 at 18:27, Michael Wild them...@gmail.com 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
On Fri, Feb 4, 2011 at 01:31, Michael Hertling mhertl...@online.de wrote:
With a Makefile generator, you might use a RULE_LAUNCH_COMPILE property:
SET_TARGET_PROPERTIES(target PROPERTIES RULE_LAUNCH_COMPILE win32fe)
Thanks for these suggestions. I went with this one, but I'll try the other
On Thu, Feb 3, 2011 at 14:42, Michael Wild them...@gmail.com 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
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
On Thu, Feb 3, 2011 at 16:33, Michael Wild them...@gmail.com 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
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)?
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
On Thu, Oct 21, 2010 at 16:52, M. Scot Breitenfeld brtn...@uiuc.edu 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,
On Wed, Oct 13, 2010 at 22:21, Alexander Neundorf
a.neundorf-w...@gmx.net wrote:
CMAKE_language_SOURCE_FILE_EXTENSIONS is used quite early in the
enable-language process, i.e. when the
CMakeFiles/CMakelanguageCompiler.cmake file is generated.
If the variable is changed after that happened, it
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)
On Tue, Oct 12, 2010 at 15:33, Michael Wild them...@gmail.com 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
On Thu, Sep 2, 2010 at 10:08, Michael Wild them...@gmail.com 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
On Mon, 30 Aug 2010 13:11:46 +0200, Giraudon Cyril cyril.girau...@free.fr
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
On Fri, 27 Aug 2010 08:10:49 -0700, Mark Roden mmro...@gmail.com 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
On Tue, 1 Jun 2010 08:43:43 -0600, Kelly Thompson k...@lanl.gov wrote:
This can be done using a Fortran compile option. For gfortran, add the
option -Mdir to CMAKE_Fortran_FLAGS.
Sure, however
1. One should use -J instead because (since 4.0), -M is deprecated to
avoid conflicts with
On Tue, 01 Jun 2010 13:02:29 -0400, Brad King brad.k...@kitware.com 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
On Tue, 01 Jun 2010 13:48:21 -0400, Brad King brad.k...@kitware.com 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
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,
On Thu, 06 May 2010 08:28:34 -0400, Bill Hoffman bill.hoff...@kitware.com
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:
On Thu, 06 May 2010 09:10:51 -0400, Bill Hoffman bill.hoff...@kitware.com
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
On Thu, 06 May 2010 09:49:37 -0400, Bill Hoffman bill.hoff...@kitware.com
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
On Thu, 6 May 2010 16:36:14 +0200, Michael Wild them...@gmail.com 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
On Thu, 6 May 2010 16:42:13 +0200, Michael Wild them...@gmail.com 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 |
On Thu, 6 May 2010 17:32:28 +0200, Michael Wild them...@gmail.com 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
On Thu, 6 May 2010 17:41:45 +0200, Michael Wild them...@gmail.com wrote:
On 6. May, 2010, at 17:37 , Jed Brown wrote:
On Thu, 6 May 2010 17:32:28 +0200, Michael Wild them...@gmail.com wrote:
Ugh, yes. So this should be (does tup accept absolute source file paths?)
/path/to/a.f90
On Thu, 6 May 2010 18:16:14 +0200, Michael Wild them...@gmail.com 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
On Wed, 05 May 2010 16:08:14 -0400, Bill Hoffman bill.hoff...@kitware.com
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
On Fri, 22 Jan 2010 10:05:19 +0100, Arjen Markus arjen.mar...@deltares.nl
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
On Fri, 22 Jan 2010 10:24:30 +0100, Marcel Loose lo...@astron.nl 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
On Fri, 22 Jan 2010 10:30:28 +0100, Michael Wild them...@gmail.com 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
On Fri, 22 Jan 2010 15:43:42 -0500, Bill Hoffman bill.hoff...@kitware.com
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
On Thu, 21 Jan 2010 15:44:43 +, Mateusz Loskot mate...@loskot.net 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
On Thu, 21 Jan 2010 17:03:27 +0100, Michael Wild them...@gmail.com 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.
On Thu, 21 Jan 2010 09:17:22 -0600, Mark Moll mm...@cs.rice.edu 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
On Fri, 15 Jan 2010 18:59:45 +0100, Alexander Neundorf
a.neundorf-w...@gmx.net 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
On Wed, 13 Jan 2010 13:51:57 +0100, Nico Schlömer nico.schloe...@gmail.com
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
On Wed, 13 Jan 2010 07:04:46 -0600, Ryan Pavlik rpav...@iastate.edu 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
On Thu, 7 Jan 2010 19:24:19 -0600, Ryan Pavlik rpav...@iastate.edu 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
On Thu, 07 Jan 2010 15:54:33 -0600, Ryan Pavlik rpav...@iastate.edu 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.
On Mon, 28 Dec 2009 12:29:05 +0100, Pau Garcia i Quiles pgqui...@elpauer.org
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
On Wed, 30 Dec 2009 17:51:29 +0100, Michael Wild them...@gmail.com wrote:
On 30. Dec, 2009, at 17:32 , Jed Brown wrote:
On Mon, 28 Dec 2009 12:29:05 +0100, Pau Garcia i Quiles
pgqui...@elpauer.org wrote:
I'm using CMake 2.8.0 on Linux. Yes, Michael is right: I want it to
happen
On Fri, 18 Dec 2009 14:45:51 -0500, Roman Shtylman shtyl...@gmail.com 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
On Fri, 18 Dec 2009 10:19:05 +0100, Marcel Loose lo...@astron.nl 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
On Thu, 03 Dec 2009 18:17:21 -0200, Rodolfo Schulz de Lima
rodo...@rodsoft.org 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
On Thu, 03 Dec 2009 16:26:19 -0200, Rodolfo Schulz de Lima
rodo...@rodsoft.org 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,
On Thu, 03 Dec 2009 16:59:01 -0200, Rodolfo Schulz de Lima
rodo...@rodsoft.org 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
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
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
Mathieu Malaterre wrote:
On Thu, Oct 29, 2009 at 7:16 PM, Alexander Neundorf
a.neundorf-w...@gmx.net 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,
Adolfo Rodríguez wrote:
On Fri, May 29, 2009 at 5:48 AM, Clinton Stimpson clin...@elemtech.comwrote:
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,
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 this particular case as with the
philosophy
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
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
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
right qmake first in your PATH
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 in the
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
installed in the
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. Frustratingly,
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 KDE4
are only co
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
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
On Wed 2009-04-08 20:50, Piotr Dobrogost wrote:
John Drescher wrote:
On Wed, Apr 8, 2009 at 2:27 PM, Piotr Dobrogost
p...@opensource.dobrogost.pl wrote:
Hi
Am I missing something or there is no operator for easy string
concatenation in cmake?
I guess its a matter of preference.
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,
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
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 use foo
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)
where test.c uses only functions defined in foo.c
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
On Mon, Jan 12, 2009 at 13:02, Bartlett, Roscoe A raba...@sandia.gov 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
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
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 error
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 get
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
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 to
-L/A -L/B -la -lb
I don't see where the above would fail.
This can
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
-L/A -L/B -la -lb
I don't see where the above would fail.
This can also fail, but I should have written
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
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
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.
The need came-in again and again
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 cleanly handled.
I agree, it's
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
On Wed 2008-11-05 21:05, Bill Hoffman wrote:
Jed Brown wrote:
On Wed 2008-11-05 23:02, Csaba Halász wrote:
Yes, I have just run into this very problem (see my earlier mail about
libtiff)
I just made some try-compile tests to check for known possible dependencies.
I hoped somebody with more
Add a flag to make find_library() only resolve to static libs and a
global switch to force this for all find_library() calls.
If I want to build a static executable on a system with both shared and
static libraries, my current solution is to run
sed -i 's/\.so\/.a/g' CMakeCache.txt
but this
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 to
-L/A -L/B -la -lb
I don't see where the above would fail.
If /A/libb exists, but is ABI-incompatible with /B/libb
I hope clarifies the core problem I rambled on about in my last message.
Suppose I am building project Foo which depends on libA which has an
optional dependency on libB. It looks like everyone just does
find_library (A_LIBRARY A)
and calls it good. If libA is a shared library, the linker
On Wed 2008-11-05 23:02, Csaba Halász wrote:
Yes, I have just run into this very problem (see my earlier mail about
libtiff)
I just made some try-compile tests to check for known possible dependencies.
I hoped somebody with more cmake experience could offer some insight,
but didn't get any
(Sorry this is so long.)
I have seen recommendations in CMake documentation to use
FOO_INCLUDE_DIR, FOO_INCLUDE_DIRS, FOO_INCLUDE_PATH, FOO_INCLUDES.
Which is preferred? The modules included with CMake 2.6.3rc1 are
extremely inconsistent on this.
PETSc provides a common interface to lots of
A minor documentation nit: readme.txt says
XXX_INCLUDE_PATH was considered bad because a path includes an actual filename
but variable type
PATH = Directory chooser dialog
while FILEPATH refers to a file. So this doesn't seem to be a valid
argument against XXX_INCLUDE_PATH, but we
1 - 100 of 102 matches
Mail list logo
