Neal Meyer wrote:
Is there any particular reasoning why for a shared library project the
.dll file is created in the LibraryOutputPath rather then the
ExecutableOutputPath. The Import library(.lib) should be placed in
the LibraryOutputPath, but it doesn't make any sense for the .dll to
be placed
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
e
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 o
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
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 d
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 a
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
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
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 l
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
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 pr
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/i
-- 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
-- TBB_LIB_DIR: /Users/Shared/Toolkits/tbb20_010/ia32/
cc4.0.1_os10.4.4/lib
-- TBB_LIBRARY:
-- Threading Building Blocks Installed in /
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?
[Awaitin
I am trying to write a FindTBB.cmake file (Intel's Threading Building
Blocks). For some reason FIND_LIBRARY is not finding "libtbb.dylib"
on my system in the location that I have it installed. HEre is my
FindTBB.cmake file:
#-- Clear the Library List
SET (TBB_LIBRARIES "")
SET (TBB_LIBRARY
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 nega
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 include glib and
> pkg-config).
> >
> > 1) does pkg-config.e
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 anoth
Is there any particular reasoning why for a shared library project the
.dll file is created in the LibraryOutputPath rather then the
ExecutableOutputPath. The Import library(.lib) should be placed in
the LibraryOutputPath, but it doesn't make any sense for the .dll to
be placed there as well.
I e
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
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
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 m
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
Alan Antonuk wrote:
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 hel
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 wo
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 i
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? :)
> -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
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 m
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
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
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
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 leas
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, X
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, X
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 FindXX
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
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
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 pro
40 matches
Mail list logo