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
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
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
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_
丁老师 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
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
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
$ 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
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
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
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 .. '-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
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
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
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
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
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")
>>
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
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
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
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
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 directory
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
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
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?
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 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
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
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
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
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
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
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
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.
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
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?)
> >>
> >&
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 |> %
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
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
__
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
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
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
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
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
__
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
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
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
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
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
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
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
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
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
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
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
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
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
_
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
>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
>
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
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
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
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
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
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 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)
> >
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
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
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
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_
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
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
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 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
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.
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
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 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
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
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 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 - 100 of 109 matches
Mail list logo