Good morning,
On Monday 10 November 2008 16:46, Bill Hoffman wrote:
OK, so perhaps the FindFoo.cmake modules should always use a try-compile
to test the library that is found works with the current ABI. This
will likely slow things down quite a bit... This would require some
extra
Le Tue, 11 Nov 2008 09:13:04 +0100,
Mathias Fröhlich [EMAIL PROTECTED] a écrit :
[...]
Perhaps the abi can be determined without a
try-compile, but I am not sure that would work on all platforms.
That would be indeed the way cmake handles these things. But this
requires plenty of
Jed Brown wrote:
My point about CC and friends is that there are often standard
environment variables for setting this stuff. I think it should be
possible to select the version of packages with one variable. For Qt4,
this is the qmake executable, for PETSc, it is (by convention) PETSC_DIR
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
Jed Brown wrote:
Thanks Bill. I'm very encouraged by the response this thread has
generated and optimistic that the Find* modules will become more robust
without undue effort by module writers.
Well, it is not going to happen over night, but I think we are closer to
a plan. I am going to
On Mon, Nov 10, 2008 at 10:09 AM, Bill Hoffman wrote:
Jed Brown wrote:
Thanks Bill. I'm very encouraged by the response this thread has
generated and optimistic that the Find* modules will become more robust
without undue effort by module writers.
Well, it is not going to happen over night,
Jed,
Just to tell you, that you are not alone with that kind of problem. I miss a
solution to that abi problems too.
I have also brought up this question every now and then, but without any
usable solution yet.
Sadly, I do not have the time to provide such a solution...
... well, and yes I
Mathias Fröhlich wrote:
The basic problem is that almost all cmake macros tend to test sideeffects
that in some special cases are related to what you need to test. But only for
special cases.
So testing for the existence of a .so in /usr/lib does in no way tell anything
if you can link with
Hi,
On Monday 10 November 2008 16:29, Bill Hoffman wrote:
Can you describe exactly what you think autotools does here? I guess
most autotools tests use a try-compile to find a library. Is that what
you are referring to?
Yep.
If you want to link with a library you need to test if you can
Miguel A. Figueroa-Villanueva wrote:
es.
- Add an easy way to create dependent cache variables, that when changed
unset a number of other variables.
A while back I had opened a feature request on the third item:
http://public.kitware.com/Bug/view.php?id=7286
I think it is a fairly simple
Miguel A. Figueroa-Villanueva wrote:
On Mon, Nov 10, 2008 at 10:09 AM, Bill Hoffman wrote:
Jed Brown wrote:
Thanks Bill. I'm very encouraged by the response this thread has
generated and optimistic that the Find* modules will become more robust
without undue effort by module writers.
Mathias Fröhlich wrote:
Hi,
On Monday 10 November 2008 16:29, Bill Hoffman wrote:
Can you describe exactly what you think autotools does here? I guess
most autotools tests use a try-compile to find a library. Is that what
you are referring to?
Yep.
If you want to link with a library you
I have created a new wiki entry here:
http://www.cmake.org/Wiki/CMake:Improving_Find*_Modules#Proposed_solutions_to_Find.2A_issues
I merge the information in these entries into the above entry:
http://www.cmake.org/Wiki/CMake:Static_libraries
Bill Hoffman wrote:
I have created a new wiki entry here:
http://www.cmake.org/Wiki/CMake:Improving_Find*_Modules#Proposed_solutions_to_Find.2A_issues
I merge the information in these entries into the above entry:
http://www.cmake.org/Wiki/CMake:Static_libraries
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 Monday 10 November 2008, Bill Hoffman wrote:
Jed Brown wrote:
Thanks Bill. I'm very encouraged by the response this thread has
generated and optimistic that the Find* modules will become more robust
without undue effort by module writers.
Well, it is not going to happen over night,
Le Sun, 09 Nov 2008 17:55:12 -0500,
Bill Hoffman [EMAIL PROTECTED] a écrit :
2. CMake needs a way to easily chain variables together so that you
can clear stuff out if a dependent variable is changed by the user.
So, if you have MY_PATH_TO_TOOL=/path/to/tool, and it changes to
Jed Brown wrote:
Is my environment not `working' simply because I'm asking to link the
versions of libraries that are found at a path other than the system
defaults? Using something else and asking the user to edit the cache is
like ignoring CC and requiring the user to edit CMAKE_C_COMPILER,
2008/11/7 Jed Brown [EMAIL PROTECTED]:
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
2008/11/7 Jed Brown [EMAIL PROTECTED]:
My current opinion is the multiple version issue should be handle
by a CRAY module-like tool and not by CMake itself.
If the underlying tool is efficient then CMake FIND module should find
the appropriate version.
Thank you Eric, this greatly clarifies
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, you should also have a working environment.
On Friday 07 November 2008 11:50:04 Jed Brown wrote:
It sounds like these all satisfy the predicate that you have shared libs
and you only have one version of each package installed (or you're
trying to find the version in the standard location).
Sure and I'd argue most people are in that
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 Friday 07 November 2008 11:02:37 Jed Brown wrote:
I had hoped that by raising the issue of widespread brokenness, there
would be some response from CMake developers about ways to fix it. It
seems like I'm still at the stage of convincing people that there is a
real problem. This is why
On 07.11.08 11:19:24, Jed Brown wrote:
My previous messages to this list, describing many forms of brokenness
in such environments, have gotten few responses (thanks Alexander, Bill,
Csaba) while everyone weighs in on the bike shed. If it's not a
priority, then CMake is little more than color
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 Friday 07 November 2008, 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, you
2008/11/7 Jed Brown [EMAIL PROTECTED]:
If the underlying tool is efficient then CMake FIND module should find
the appropriate version.
Thank you Eric, this greatly clarifies some design decisions. May I
interpret this to mean that CMake does not intend to be concerned with
finding the
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 and
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
32 matches
Mail list logo
