Hi,
On Thursday 27 September 2007 16:31, Bill Hoffman wrote:
I think there's a way to tell CMake to either use lib or lib64,
something like LIB_SUFFIX.
CMake does a test for sizeof void* if it is 8 bytes then lib64 is
searched before lib in all FIND_* stuff.
That is way too croase and
Neal Meyer a écrit :
Richard,
This project organization is much better, Kudos. However, most of our
directories include only a single project file so there seems to be a
lot of redundant folders in this type of layout, so maybe a little
additional feature that if there is only a single
On 28.09.07 07:47:50, Mathias Froehlich wrote:
Hi,
On Thursday 27 September 2007 15:53, Andreas Pakulat wrote:
Just to state the obvious: Thats backwards compared to what distro's
have these days. */lib is always the native libs and then you have
either lib64 or lib32 (at least AFAIK,
On Friday 28 September 2007 16:36:00 Mathias Froehlich wrote:
Mathias Froehlich wrote:
to time. I am not sure that FIND_LIBRARY should do a try_compile, but
maybe it should
Probably yes.
IMO, better test what you need rather than test something that is more or
less closely related
On Friday 28 September 2007 14:56, you wrote:
Mathias Froehlich wrote:
Hi,
On Thursday 27 September 2007 16:31, Bill Hoffman wrote:
I think there's a way to tell CMake to either use lib or lib64,
something like LIB_SUFFIX.
CMake does a test for sizeof void* if it is 8 bytes then
Am I correct in thinking that cmake doesn't support build types for make
files? It doesn't seem to matter what I do with
CMAKE_CONFIGURATION_TYPES, when I generate a set of make files, they
appear to be created for a single generic target.
Is there a 'canonical' way of coaxing cmake to generate
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Bill Hoffman wrote:
Mathias Froehlich wrote:
Hi,
That is way too croase and will even bring the wrong results.
It produces good results on linux x64 and itanium platforms. I have
tested and
Can anyone explain me why
the default CMAKE_xxx_LIBRARY_PREFIX
used for MinGW compiler is 'lib' and not ''.
When I compile my lib marvelous
on windows:
- using CMake + Visual Studio I get :
marvelous.dll
- using CMake + MinGW I get:
libmarvelous.dll
this seems un-homogeneous choice
How are you arranging this, would you be able to let me see some of your
CMakeList.txt files? It looks to me that I'm hitting a lot of edge
cases in cmake, and It's not clear from the documentation, what the
right way of doing this is.
Can you help me avoid banging my head against the wall?
Mathias Froehlich wrote:
Hi,
On Thursday 27 September 2007 16:31, Bill Hoffman wrote:
I think there's a way to tell CMake to either use lib or lib64,
something like LIB_SUFFIX.
CMake does a test for sizeof void* if it is 8 bytes then lib64 is
searched before lib in all FIND_* stuff.
Hello list,
I wonder what the difference is between making the target
$ make rebuild_cache
and a run of
$ cmake /path/to/CMakeLists.txt
Joachim
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Update:
I've ported the bootstrap script to DCL (yuck) and it has most of the
functionality of the bash version of the script.
I decided to take a dependency on the A9 porting library a.k.a. The
Jackets (http://h71000.www7.hp.com/openvms/products/ips/porting.html) to
help with some of the small
Hi all,
I have a couple of comments/questions:
1.- I have a bunch of tests that I expect many people will not run all
the time so I excluded them from the 'all' target using EXCLUDE_FROM_ALL.
The problem then was that when I did 'make test', the tests were not
build. I thought that dependency
Isn't the lib prefix simply the default you would get if you built a
dll (even without cmake) with MinGW gcc?
On 9/28/07, Eric Noulard [EMAIL PROTECTED] wrote:
Can anyone explain me why
the default CMAKE_xxx_LIBRARY_PREFIX
used for MinGW compiler is 'lib' and not ''.
When I compile my lib
2007/9/28, David Cole [EMAIL PROTECTED]:
Isn't the lib prefix simply the default you would get if you built a
dll (even without cmake) with MinGW gcc?
That I don't really know.
But I would think that you _MUST_ specify the output name
using -o option just like you would with gcc when
you build
On 9/27/07, Hendrik Sattler [EMAIL PROTECTED] wrote:
Am Freitag 28 September 2007 schrieb Brandon Van Every:
I can't see why any CMake-oriented person would
recommend pkg-config unless they're stuck with it as a legacy concern.
And with a cmake centric solution, you create yet another
Answering my own question, after a bit of research, it appears that
cmake doesn't natively deal with cross-platform building for Visual
Studio Projects. Instead it tests to see whether to generate Win32 or
x64 project file configurations.
In the environment we've got, we want to build Win32,
Eric Noulard wrote:
2007/9/28, David Cole [EMAIL PROTECTED]:
Isn't the lib prefix simply the default you would get if you built a
dll (even without cmake) with MinGW gcc?
That I don't really know.
But I would think that you _MUST_ specify the output name
using -o option just like you
I'm having some trouble getting a clean way to set the warning level
in my projects with Visual Studio 2005.
When I try this
SET(CMAKE_C_WARNING_LEVEL 4)
SET(CMAKE_CXX_WARNING_LEVEL 4)
It seems to be ignored because the project files still have the
warning level set to 3. I only want to turn
On 28.09.07 03:23:01, Hendrik Sattler wrote:
Am Freitag 28 September 2007 schrieb Brandon Van Every:
On 9/27/07, Andreas Pakulat [EMAIL PROTECTED] wrote:
I'm reporting 2nd hand information from people that have long-time
experience with pkg-config. Unfortunately I can't find the thread on
On 28.09.07 03:31:26, Hendrik Sattler wrote:
Am Freitag 28 September 2007 schrieb Andreas Pakulat:
On 27.09.07 16:07:46, Alan W. Irwin wrote:
On 2007-09-27 21:53+0200 Andreas Pakulat wrote:
No it doesn't work properly on win32 - AFAIK. Thats the reason why all
cmake FindXXX modules for
Answering my own question, after a bit of research, it appears that
cmake doesn't natively deal with cross-platform building for Visual
Studio Projects. Instead it tests to see whether to generate Win32 or
x64 project file configurations.
In the environment we've got, we want to build Win32,
On 2007-09-28 11:51+0200 Andreas Pakulat wrote:
On 28.09.07 03:31:26, Hendrik Sattler wrote:
I only used it with msys so far and it's working, there, using the GLIB dll
and the provided pre-compiled pkgconfig binary.
Yeap, thats a problem already.
Sorry, Andreas, but in your rush to be
Could you post the output that occurs when you run this script...?
One thing I notice is that you are setting TBB_LIBRARY to YES -- is
that really what you want? If so, it should probably not be added to
the list of TBB_LIBRARIES, which is presumably a list of libs to link
against?
[Awaiting
Is this line:
SET(TBB_LIBRARY YES)
supposed to be this:
SET(TBB_FOUND YES)
??
On 9/28/07, Mike Jackson [EMAIL PROTECTED] wrote:
-- TBB_INSTALL_DIR: /Users/Shared/Toolkits/tbb20_010/ia32/
cc4.0.1_os10.4.4
-- TBB_INCLUDE_DIR: /Users/Shared/Toolkits/tbb20_010/ia32/
cc4.0.1_os10.4.4/include
On 28.09.07 11:23:15, Alan W. Irwin wrote:
On 2007-09-28 11:51+0200 Andreas Pakulat wrote:
On 28.09.07 03:31:26, Hendrik Sattler wrote:
I only used it with msys so far and it's working, there, using the GLIB dll
and the provided pre-compiled pkgconfig binary.
Yeap, thats a problem
On 2007-09-28 21:32+0200 Andreas Pakulat wrote:
Well, anyway, tried it and there we are, unix-paths in the output so
there's no way these flags can be used in a win32 native environment.
However looking at the .pc files and the output of pkg-config as well as
pkg-config --help it seems that at
On 9/28/07, Brandon Van Every [EMAIL PROTECTED] wrote:
On 9/27/07, Alan W. Irwin [EMAIL PROTECTED] wrote:
On 2007-09-27 16:12-0400 Brandon Van Every wrote:
http://www.gimp.org/~tml/gimp/win32/downloads.html is a site that contains
windows binaries for the libgtk+ dependencies (which
On 9/28/07, Alan W. Irwin [EMAIL PROTECTED] wrote:
It appears from what you said that the pkg-config executable actually runs
in the non-MSYS case which exactly confirms what is claimed by the
pkg-config website.
You are making way too much of the claim on the website. It claims
that it runs
2007/9/28, Bill Hoffman [EMAIL PROTECTED]:
The lib prefix is so that gcc can automatically link to the library with
the usual -L -l stuff.
From my very first today experience giving up the 'lib' prefix
is OK with mingw on a windows box (did not try a cross compiler though)
Moreover, from the
No need to Cc me, I'm reading the list.
On 28.09.07 13:37:08, Alan W. Irwin wrote:
On 2007-09-28 21:32+0200 Andreas Pakulat wrote:
Well, anyway, tried it and there we are, unix-paths in the output so
there's no way these flags can be used in a win32 native environment.
However looking at the
Setting the architecture CMakeLists.txt is a rather crude solution in
itself since then you'd have to manually change the architecture in
that file. Sure you can make a small script that does this by
executing dpkg --print-architecture, but it seems like a lot of fuzz
for something that has to be
On 2007-09-28 17:02-0400 Brandon Van Every wrote:
On 9/28/07, Alan W. Irwin [EMAIL PROTECTED] wrote:
It appears from what you said that the pkg-config executable actually runs
in the non-MSYS case which exactly confirms what is claimed by the
pkg-config website.
You are making way too much
On 9/28/07, Alan W. Irwin [EMAIL PROTECTED] wrote:
On 2007-09-28 17:02-0400 Brandon Van Every wrote:
Andreas didn't say it works in any usable sense. He said it gives
some kind of output.
But that output sounded like exactly what you expect from pkg-config
(compile and link options with
Andreas, you should calm down. Nobody is forcing you to use pkg-config.
However, your various negative generalizations do not convince me since
pkg-config has been great for PLplot and many other Linux packages, and it
it appears it is going to be completely straightforward (thanks to cmake) to
35 matches
Mail list logo
