On Tue, Feb 17, 2009 at 4:26 PM, Eric Noulard wrote:
> 2009/2/16 Bill Hoffman :
> > Philip Lowman wrote:
> >>
> >> A tertiary goal would be convincing the 3rd party dependencies to switch
> >> to CMake for their native build systems.
>
> I don't really like the "propaganda" idea :-)
>
> Particular
On Tue, Feb 17, 2009 at 4:19 PM, Eric Noulard wrote:
> 2009/2/17 Eric Noulard :
> > 2009/2/17 Alexander Neundorf :
> >>>
> >>> But a http://autoconf-archive.cryp.to/ type archive for CMake modules
> >>> would also be a good idea.
> >>
> >> At FOSDEM we also discussed about something like this, som
I get a lot of these warnings (example below), because in
/usr/lib64 there are symlinks to the libGL files in
/usr/X11R6/lib64
Is there a correct (but still safe) way to make these warnings go away.
There are a lot of them (a couple per plugin - so on screen we get tens
of copies of the warning
On Tue, Feb 17, 2009 at 12:09 PM, Bill Hoffman wrote:
> Also, it would be really great if we setup a dashboard for this project. I
> am thinking it could all be checked out and built on a variety of
> compilers/OS's nightly.
Wouldn't have it any other way. :)
--
Philip Lowman
On Tue, Feb 17, 2009 at 12:34 PM, Pau Garcia i Quiles
wrote:
> Hello,
>
> I want Visual C++ to output executables, DLLs, etc to the builddir
> without creating "Release", "Debug", "RelWithDebInfo", etc
> directories. In our case, this would be very convenient for debugging.
>
> I have found the CM
I wasn't able to get a copy, but it's in kde svn
/kde-svn/src/trunk/koffice/*cmake*/modules/
Kaveh Kohan wrote:
Dear CMake users,
I am trying to use gmm++ in my code. I read somewhere on web that
FindGMM.cmake is available. I don't know from where I can download it.
I would be thankful if
Eric Noulard wrote:
2009/2/16 Bill Hoffman :
Philip Lowman wrote:
A tertiary goal would be convincing the 3rd party dependencies to switch
to CMake for their native build systems.
I don't really like the "propaganda" idea :-)
Particularly for Open Source projects.
Open Source is about choic
Dear CMake users,
I am trying to use gmm++ in my code. I read somewhere on web that
FindGMM.cmake is available. I don't know from where I can download it.
I would be thankful if you share it with me or in case it is online,
let me know where/how I can get it.
Regards,
Kaveh
ps: Sorry if this is
On Tuesday 17 February 2009 20:30:07 Michael Jackson wrote:
> Yep. Silly me, expecting ncurses to be installed by default..
It is, just not the development headers.
--
Cheers,
Mike Arthur
http://mikearthur.co.uk/
___
Powered by www.kitware.com
Visit ot
2009/2/16 Bill Hoffman :
> Philip Lowman wrote:
>>
>> A tertiary goal would be convincing the 3rd party dependencies to switch
>> to CMake for their native build systems.
I don't really like the "propaganda" idea :-)
Particularly for Open Source projects.
Open Source is about choice and openess.
2009/2/17 Eric Noulard :
> 2009/2/17 Alexander Neundorf :
>>>
>>> But a http://autoconf-archive.cryp.to/ type archive for CMake modules
>>> would also be a good idea.
>>
>> At FOSDEM we also discussed about something like this, some kind of
>> semi-official place where to get additional cmake files
2009/2/17 Alexander Neundorf :
>>
>> But a http://autoconf-archive.cryp.to/ type archive for CMake modules
>> would also be a good idea.
>
> At FOSDEM we also discussed about something like this, some kind of
> semi-official place where to get additional cmake files.
> Right now you can look in sev
2009/2/17 Michael Jackson :
> I'll try that. I just did the apt-get thing to install the libncurses5-dev
> package and the cmake boot strapper still can not find the curses library.
I do build CMake 2.6-patch 3 RC-13 on Debian Lenny amd64
and ccmake did build fine.
However I did not bootstrap,
On Feb 15, 2009, at 8:15 PM, Robert Haines wrote:
I'd be interested in your feedback if you look at them. I don't have
a situation at the moment where I need a certain version of python
for my code which is why this issue totaly past me by so far.
The scripts included worked well. I create
I'll try that. I just did the apt-get thing to install the libncurses5-
dev package and the cmake boot strapper still can not find the curses
library.
---
Mike Jackson www.bluequartz.net
On Feb 17, 2009, at 3:27 PM, David E DeMarle wrote:
I recently did a 64 bit ubuntu cm
Yep. Silly me, expecting ncurses to be installed by default..
---
Mike Jackson www.bluequartz.net
On Feb 17, 2009, at 3:25 PM, David E DeMarle wrote:
I recently did a 64 bit ubuntu cmake build and had the same outcome.
I installed curses (from package I think) then ccmake bui
> I recently did a 64 bit ubuntu cmake build and had the same outcome.
> I installed curses (from package I think) then ccmake built for me.
make that ncurses 5.7 built from source.
> On Tue, Feb 17, 2009 at 3:21 PM, Michael Jackson
> wrote:
>> Just tried building cmake from source on Linux X86_
I recently did a 64 bit ubuntu cmake build and had the same outcome.
I installed curses (from package I think) then ccmake built for me.
On Tue, Feb 17, 2009 at 3:21 PM, Michael Jackson
wrote:
> Just tried building cmake from source on Linux X86_64 (KUbuntu running
> inside Sun's Virtual Box envi
On Tuesday 17 February 2009, Bill Hoffman wrote:
> Aaron Turner wrote:
...
> > Honestly, I think in the long run, improving the existing standard
> > library of Cmake modules to allow developers to concentrate on how to
> > build their own code rather then figure out how to link to various
> > libr
Just tried building cmake from source on Linux X86_64 (KUbuntu running
inside Sun's Virtual Box environment. The only thing that got built
was cmake, cpack and ctest. Where is ccmake at? I looked through the ./
configure --help and nothing really jumped out at me.
Thanks
BRM wrote:
I read through this thread, and I think there may be a better route -
Instead of trying to create all kinds of patches, etc; why not make a
simple tool to convert an autotool project to CMake and vice-versa?
Perhaps call it 'autotool2cmake'?
This way, the process becomes simpler:
Aaron Turner wrote:
Trying to get up to speed on this thread- apologies if I missed this.
Long story short, as an OSS developer and new Cmake user, I'm less
interested in getting libfoo building with Cmake and a lot more
interested in CMake modules for detecting and using libfoo in my own
projec
I read through this thread, and I think there may be a better route -
Instead of trying to create all kinds of patches, etc; why not make a simple
tool to convert an autotool project to CMake and vice-versa? Perhaps call it
'autotool2cmake'?
This way, the process becomes simpler:
1) Download s
Trying to get up to speed on this thread- apologies if I missed this.
Long story short, as an OSS developer and new Cmake user, I'm less
interested in getting libfoo building with Cmake and a lot more
interested in CMake modules for detecting and using libfoo in my own
project. In reality, these
AddExternalProject is related. It can be used to download files as custom
build steps. (And then configure, build, install... other projects.)
It is only in CVS CMake right now, but it is on its way to maturing to the
point where it could be used for a project like this fairly quickly.
On Tue, F
Bill Hoffman ha scritto:
Philip Lowman wrote:
For the first cut I think starting out with keeping the CMakified
sources in the project would be fine. Many people are never going to
want anything more complicated than this and we know that this will
at least work for now.
CMake can alread
On Tuesday 17 February 2009 17:34:20 Pau Garcia i Quiles wrote:
> I want Visual C++ to output executables, DLLs, etc to the builddir
> without creating "Release", "Debug", "RelWithDebInfo", etc
> directories. In our case, this would be very convenient for debugging.
>
> I have found the CMAKE_INTDI
On Tuesday 17 February 2009, Micha Renner wrote:
> In a top-level CMakeLists I have the following lines
>
> PROJECT(BuildDLL14)
>
> CMAKE_MINIMUM_REQUIRED(VERSION 2.6)
> SET(CMAKE_MODULE_PATH "/usr/local/share/CMake")
> SET(CMAKE_INSTALL_PREFIX ${CMAKE_BINARY_DIR})
>
> ADD_SUBDIRECTORY(DLL-1)
> ADD
On Tuesday 17 February 2009, you wrote:
...
> Of course, you can debate forever whether such a SF project would be
> successful or not, but the only way to really know is to try it and see.
> That is, start with something small and expand from there. I don't have
> time to help with such a SF proje
Hello,
I want Visual C++ to output executables, DLLs, etc to the builddir
without creating "Release", "Debug", "RelWithDebInfo", etc
directories. In our case, this would be very convenient for debugging.
I have found the CMAKE_INTDIR and CMAKE_CFG_INTDIR variables but
neither SET( CMAKE_INTDIR ".
Patrick Spendrin wrote:
Does this sound interesting?
Yes.
As I am maintaining patches for some libraries and working for some
others, it would be nice to have such a unified system to keep doubled
work amount low.
This has some more points:
We would not have to maintain our patches in our ow
I suspect you are right about me running the wrong ctest. Sorry for the
false alarm there. Glad the docs will be fixed though.
.. Original Message ...
On Tue, 17 Feb 2009 09:31:40 -0500 "Bill Hoffman"
wrote:
>Bill Hoffman wrote:
>> Philip Lowman wrote:
>>>
>>> I've reopened this featu
Philip Lowman wrote:
For the first cut I think starting out with keeping the CMakified
sources in the project would be fine. Many people are never going to
want anything more complicated than this and we know that this will at
least work for now.
CMake can already untar with -E mode. Add
Bill Hoffman wrote:
Philip Lowman wrote:
I've reopened this feature request as a bug because
1.) using "ctest" does not work
2.) the ENVIRONMENT test property is not documented
Discovered both of these issues tonight after looking into Ankit's
request and vaguely recalling this being implemen
Philip Lowman wrote:
I've reopened this feature request as a bug because
1.) using "ctest" does not work
2.) the ENVIRONMENT test property is not documented
Discovered both of these issues tonight after looking into Ankit's
request and vaguely recalling this being implemented in CVS.
http://
I would say that something isn't quite setup correctly with your cmake
project because lots of us use this technique and it works as
advertised. All I can think of is there is a loss of a dependency
somewhere.
---
Mike Jackson www.bluequartz.net
On Feb 17, 2009, at 1:35 A
INCLUDE(CheckCXXSourceCompiles)
CHECK_CXX_SOURCE_COMPILES(
"#include \"wchar.h\"
static void testcb(wint_t w) { }
int main() {
wint_t w = 0;
testcb(w);
return 0;
}"
HAVE_WINT_T)
message(STATUS "HAVE_WINT_T: ${HAVE_WINT_T}")
If you start with runetype.h and
On Tue, Feb 17, 2009 at 6:54 AM, Mike Arthur wrote:
> On Tuesday 17 February 2009 02:24:17 Alan W. Irwin wrote:
> > Of course, you can debate forever whether such a SF project would be
> > successful or not, but the only way to really know is to try it and see.
> > That is, start with something s
On Mon, Feb 16, 2009 at 6:41 PM, Luigi Calori wrote:
> Alexander Neundorf ha scritto:
>
> I do not see value in keeping sources (as VTK does) apart from avoid the
> download-expand step.
> If the cmake scripts use glob rex expr to get source files, it should be
> quite resilient to project change
On Mon, Feb 16, 2009 at 4:36 PM, Alexander Neundorf wrote:
> > Since many of the dependencies overlap, is there general interest in
> this
> > kind of a thing from the VTK perspective or from others?
> >
> > The goal would be to create an open-source project (hosted probably at a
> > neutral sit
On Tuesday 17 February 2009 02:24:17 Alan W. Irwin wrote:
> Of course, you can debate forever whether such a SF project would be
> successful or not, but the only way to really know is to try it and see.
> That is, start with something small and expand from there. I don't have
> time to help with s
In a top-level CMakeLists I have the following lines
PROJECT(BuildDLL14)
CMAKE_MINIMUM_REQUIRED(VERSION 2.6)
SET(CMAKE_MODULE_PATH "/usr/local/share/CMake")
SET(CMAKE_INSTALL_PREFIX ${CMAKE_BINARY_DIR})
ADD_SUBDIRECTORY(DLL-1)
ADD_SUBDIRECTORY(TestDLL)
--
2009/2/17 Gaëtan Lehmann :
>
> Hi,
>
> I wonder, is there an option in cmake to check that a custom command has
> produced the files it should have produced?
I don't think there is such option.
However if you have the list of supposedly produced files you may
check if they have been produced with
> Yes but you may still want to separate BUILD from SOURCE tree
> and install in
>
> ${PROJECT_BINARY_DIR}/bin
Thanks, I'll consider this option too. I can't use it at the moment
though since users of the app got used to the "bin" directory in the
top level of the source tree...
> That's right, i
2009/2/17 Pavel Shevaev :
>> If your binary to install is a CMake target (like in your example)
>> you should use:
>>
>> install(targets foo
>>RUNTIME DESTINATION ${foo_SOURCE_DIR}/bin)
>>
>
> This one didn't work neither :(
>
>> moreover installing in ${foo_SOURCE_DIR} is a bit strang
Hi,
I wonder, is there an option in cmake to check that a custom command
has produced the files it should have produced?
In my case, doxygen may not produce all the expected files, depending
on the comment it finds in the source code, but install of the man
pages will fail because of those
Hmlooks like this topic already popped up in the past -
http://www.mail-archive.com/cmake@cmake.org/msg06916.html
--
Best regards, Pavel
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/
> If your binary to install is a CMake target (like in your example)
> you should use:
>
> install(targets foo
>RUNTIME DESTINATION ${foo_SOURCE_DIR}/bin)
>
This one didn't work neither :(
> moreover installing in ${foo_SOURCE_DIR} is a bit strange,
Well, there is a reason for this.
48 matches
Mail list logo
