On 2009-12-08 13:59+1200 Hugh Sorby wrote:
I am trying to use INSTALL( EXPORT ... but failing. I have a project like
this
ImageMagick/CMakeLists.txt -- 1.
ImageMagick/magick/CMakeLists.txt -- 2.
ImageMagick/coders/CMakeLists.txt -- 3.
1. calls ADD_SUBDIRECTORY for both 2 and 3
2. has a tar
I am trying to use INSTALL( EXPORT ... but failing. I have a project
like this
ImageMagick/CMakeLists.txt -- 1.
ImageMagick/magick/CMakeLists.txt -- 2.
ImageMagick/coders/CMakeLists.txt -- 3.
1. calls ADD_SUBDIRECTORY for both 2 and 3
2. has a target "magick" that is a library
3. has a targe
On Tue, Dec 8, 2009 at 12:21 AM, Glenn Hughes wrote:
> Thanks Pau,
>
> Interesting! If I remove the #include "moc_main.cxx" line, then the
> generated moc file includes "main.h", so then everything will build. I guess
> moc auto-detects which method you are using, and generates its code
> accordin
On Mon, Dec 7, 2009 at 11:54 PM, Glenn Hughes wrote:
> I'm still playing around with the states Qt example, and I've hit something
> I don't understand:
>
> I can get everything working as expected with QT4_AUTOMOC, but not if I use
> QT4_WRAP_CPP.
>
> In the QT4_WRAP_CPP case, it seems the only w
I'm still playing around with the states Qt example, and I've hit something
I don't understand:
I can get everything working as expected with QT4_AUTOMOC, but not if I use
QT4_WRAP_CPP.
In the QT4_WRAP_CPP case, it seems the only way to get dependencies set up
correctly is to add the MOC output t
Pau Garcia i Quiles
writes:
>> My advice is to start small: with a text editor, edit the top-level
>> project file, then edit the project file of lib/System, which does not
>> depend on any other file. Move the whole tree to somewhere else, open VS
>> and build just the System library. If it work
On Dec 7, 2009, at 4:42 PM, Óscar Fuentes wrote:
Bill Hoffman
writes:
[snip]
Even with the IDE based files if you are using install rules, then
the
CMake executable must be available on the machine doing the
install. CMake is also used as the program to do the install
commands.
So, CMa
> One thing of note: In order for QT4_AUTOMOC to work, I had to move the
> definition of the Pixmap class into a new header file named main.h. It seems
> in general putting your Q_OBJECT class defs in a header is required when
> building Qt projects under CMake... but there's probably some way arou
Bill Hoffman
writes:
[snip]
> Even with the IDE based files if you are using install rules, then the
> CMake executable must be available on the machine doing the
> install. CMake is also used as the program to do the install commands.
> So, CMake is really required for a variety of reasons.
Bu
Posting a solution to my previous problem
I wasn't linking in the generated resource file.
Here's a working very short CMake file for building the "states" Qt4.6
example:
---
#basic stuff
PROJECT(states) # the name of your project
CMAKE_MINIMUM_REQUIRED(VERSION 2.4.0)
#find qt, and include qt ma
On Mon, Dec 7, 2009 at 10:36 PM, Óscar Fuentes wrote:
> steve naroff writes:
>
>> Our current thinking is to post process the cmake generated files and
>> remove all the absolute paths (since the project files are simply
>> text). Since cmake is a black box to me (and I am unfamiliar with it's
>>
steve naroff writes:
> Our current thinking is to post process the cmake generated files and
> remove all the absolute paths (since the project files are simply
> text). Since cmake is a black box to me (and I am unfamiliar with it's
> generated 'code'), it's unclear if this a 'good' idea? Or wil
Brad King writes:
[snip]
> In return for the above explanation, I request an explanation as to
> the restrictions that make distributing CMake so hard, particularly
> on machines that already have the entire GNU toolchain. Have you
> ever tried to build GCC 4.4 and all its dependencies from scr
On Monday 07 December 2009, steve naroff wrote:
> Thanks for your comments Oscar.
>
> Our current thinking is to post process the cmake generated files and
> remove all the absolute paths (since the project files are simply
> text). Since cmake is a black box to me (and I am unfamiliar with it's
>
2009/12/7 Michael Jackson :
>
> Just thinking out loud .. What if CMake had a "built-in" facility to check a
> common internet location for new/updated modules like a lot of programs do
> now-and-days. This (in my mind) would allow for the deployment of "Official"
> CMake modules (or at least those
One more thing to keep in mind, is that CMake executables are heavily
used by the Makefiles during build time. CMake is used to compute depend
information. CMake is used to keep the files makefiles up to date with
the sources. Even if you did not want to auto-rerun CMake when a
CMakeLists.tx
On Dec 7, 2009, at 3:37 PM, Eric Noulard wrote:
2009/12/7 Nicholas Yue :
Hi,
Does it make sense to separate out the development and deployment
of
"Modules" in CMake?
This kind of idea have already been raised on the ML.
May be you should dig the ML archive in order to collect past idea
On 7. Dec, 2009, at 18:31 , steve naroff wrote:
On Dec 7, 2009, at 9:17 AM, Eric Noulard wrote:
2009/12/7 steve naroff :
As Eric pointed out, you must add CMake to your compiler build
chain.
It's one more tool (and with no third-party dependencies), like
the C
preprocessor, the C compile
2009/12/7 Nicholas Yue :
> Hi,
>
> Does it make sense to separate out the development and deployment of
> "Modules" in CMake?
This kind of idea have already been raised on the ML.
May be you should dig the ML archive in order to collect past ideas
in order to see past pro- and cons- the main ide
On Monday 07 December 2009 01:28:48 pm Glenn Hughes wrote:
> Hi all,
>
> Is FindQT4 documented anywhere? I've found it referenced through a few
> examples, but googling for it mostly yields bug reports rather than
> information.
>
> Thanks!
> Glenn
http://www.cmake.org/cmake/help/cmake-2-8-docs.ht
On Mon, Dec 7, 2009 at 9:28 PM, Glenn Hughes wrote:
> Hi all,
>
> Is FindQT4 documented anywhere? I've found it referenced through a few
> examples, but googling for it mostly yields bug reports rather than
> information.
$ cmake --help-module FindQt4
--
Pau Garcia i Quiles
http://www.elpauer.o
Hi all,
Is FindQT4 documented anywhere? I've found it referenced through a few
examples, but googling for it mostly yields bug reports rather than
information.
Thanks!
Glenn
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
ht
Hi,
Does it make sense to separate out the development and deployment of
"Modules" in CMake?
I see an advantage because Modules update are more frequent as more
packages are added compare to the release cycle of CMake itself.
Maybe there is an easier way? Environment variable to po
Greetings,
Not sure how to address the following to the maintainer of FindFreetype, so
sending it to this list...
FindFreetype unconditionally sets FREETYPE_LIBRARIES to whatever
FREETYPE_LIBRARY is, even when it is not found. Many other FindXXX modules
wrap the creation of their XXX_LIBRARIE
Michael Jackson wrote:
On Dec 7, 2009, at 1:28 PM, troy d. straszheim wrote:
Michael Jackson wrote:
So you are wanting to include the Boost sources in your project and
you just want to build a specific subset of Boost to use with your
project?
Here's what I came up with:
http://sodium.re
On Dec 7, 2009, at 1:28 PM, troy d. straszheim wrote:
Michael Jackson wrote:
So you are wanting to include the Boost sources in your project and
you just want to build a specific subset of Boost to use with your
project?
Here's what I came up with:
http://sodium.resophonic.com/boost-cma
Hi Steve,
FYI, I've been a CMake core developer since 2001.
steve naroff wrote:
From my perspective, not being able to use relative paths just seems
'broken'. The reason for this limitation is totally unclear to someone
like me (who is an 'end user' of cmake). I'd love to hear a thoughtful
2009/12/7 steve naroff :
>> Could you explain that part?
>> Who else is building LLVM/clang besides developers?
>> And what are the reason they give for not wanting to install CMake
>> with their compiler?
>>
> Hi Eric,
>
> With all due respect, I'd like to avoid any explanation. You'll just have t
Michael Jackson wrote:
So you are wanting to include the Boost sources in your project and you
just want to build a specific subset of Boost to use with your project?
Here's what I came up with:
http://sodium.resophonic.com/boost-cmake/current-docs/exported_targets.html#with-boost-source-i
On Dec 7, 2009, at 9:17 AM, Eric Noulard wrote:
2009/12/7 steve naroff :
As Eric pointed out, you must add CMake to your compiler build
chain.
It's one more tool (and with no third-party dependencies), like
the C
preprocessor, the C compiler and the linker. We did that at work and
it's no
Please keep on list so that others may benefit/help
So you are wanting to include the Boost sources in your project and
you just want to build a specific subset of Boost to use with your
project?
I guess I might try setting the
# Set what boost libraries will be built
BUILD_PROJECTS=file_s
On Mon, Dec 07, 2009 at 05:53:37PM +0100, Matthias Moeller wrote:
> Our project has the following structure:
>
> root/applications (Applications by different users)
> applications/app1
> applications/app2
> applications/...
>
> root/kernel (common kernel source files)
>
> root/lib
Yes this looks like an option. Thanks for the lead. It is not quite
what I was expecting.
This seems specific to Boost Libraries. Which brings up 2 questions:
Is there a generic way do this for any third party source tree?
Is there going to be CMAKE variable name resolution clash potential
I am new to Cmake and I am looking for some ideas (what to read, where
to search) on how to solve the following problem.
Our project has the following structure:
root/applications (Applications by different users)
applications/app1
applications/app2
applications/...
root/kernel (
Thanks for your fast reply!
Cedric GESTES wrote:
Yep I did. in fact with openembedded, not openwrt.
You need a toolchain.cmake file to be passed to cmake. This file will
configure cmake to use your cross-tool-chain. (compiler and staged library).
Ok, so you first run cmake using the toolchai
Yep I did. in fact with openembedded, not openwrt.
You need a toolchain.cmake file to be passed to cmake. This file will
configure cmake to use your cross-tool-chain. (compiler and staged library).
see: http://www.cmake.org/Wiki/CMake_Cross_Compiling
On Mon, Dec 7, 2009 at 4:05 PM, Tim Just wr
Hi,
we want to use CMake as replacement of GNU Autotools within a research
project. The CMake build system for Unix platforms is almost working.
The next step would be to build our project within OpenWrt[1]. Because
autotools is widely used in combination with OpenWrt, there was little
effor
Well, I'll put the xml here but keep in mind I've never edited it
directly. Hudson is configurable entirely through the web interface.
All I did was fill out a few text boxes to point it to the source
repository, which scripts to run on a build, and which files to
archive when it's done. Still, the
2009/12/7 steve naroff :
>> As Eric pointed out, you must add CMake to your compiler build chain.
>> It's one more tool (and with no third-party dependencies), like the C
>> preprocessor, the C compiler and the linker. We did that at work and
>> it's no big deal, people are so happy with the pro's
On Mon, 2009-12-07 at 14:18 +0100, Olivier Pierard wrote:
> Marcel Loose wrote:
> > On Mon, 2009-12-07 at 13:19 +0100, Mathieu Malaterre wrote:
> >
> >> On Mon, Dec 7, 2009 at 11:43 AM, Marcel Loose wrote:
> >>
> >>> Hi Olivier,
> >>>
> >>> I think you need to set the global property FIND_
Hi all,
Sorry for the noise. Must be the Monday morning blues.
HDF5_FOUND is of course set by FPHSA. Don't know exactly what's going
wrong in my script, but it certainly has nothing to do with
FindHDF5.cmake.
Best regards,
Marcel Loose.
--- Begin Message ---
Hi all,
I noticed that FindHDF5.c
On Dec 7, 2009, at 7:58 AM, Pau Garcia i Quiles wrote:
On Mon, Dec 7, 2009 at 1:04 PM, steve naroff
wrote:
Thanks for your comments Oscar.
Our current thinking is to post process the cmake generated files
and remove
all the absolute paths (since the project files are simply text).
Since
Marcel Loose wrote:
> On Mon, 2009-12-07 at 13:19 +0100, Mathieu Malaterre wrote:
>
>> On Mon, Dec 7, 2009 at 11:43 AM, Marcel Loose wrote:
>>
>>> Hi Olivier,
>>>
>>> I think you need to set the global property FIND_LIBRARY_USE_LIB64_PATHS
>>> to OFF.
>>>
>>> BTW, I disagree with Mathieu t
On Mon, Dec 7, 2009 at 1:04 PM, steve naroff wrote:
> Thanks for your comments Oscar.
>
> Our current thinking is to post process the cmake generated files and remove
> all the absolute paths (since the project files are simply text). Since
> cmake is a black box to me (and I am unfamiliar with it
Hi all,
I noticed that FindHDF5.cmake does not set HDF5_FOUND, although it says
in the documentation of the file that it does. This is both with CMake
2.8 and with the CVS HEAD.
Should I open an issue for this in the bug tracker, or is this bug too
trivial for that.
Best regards,
Marcel Loose.
On Mon, 2009-12-07 at 13:19 +0100, Mathieu Malaterre wrote:
> On Mon, Dec 7, 2009 at 11:43 AM, Marcel Loose wrote:
> > Hi Olivier,
> >
> > I think you need to set the global property FIND_LIBRARY_USE_LIB64_PATHS
> > to OFF.
> >
> > BTW, I disagree with Mathieu that building 32-bit libraries/execut
On Mon, Dec 7, 2009 at 11:43 AM, Marcel Loose wrote:
> Hi Olivier,
>
> I think you need to set the global property FIND_LIBRARY_USE_LIB64_PATHS
> to OFF.
>
> BTW, I disagree with Mathieu that building 32-bit libraries/executables
> on a 64-bit system is cross-compilation. These binaries can be run
Thanks for your comments Oscar.
Our current thinking is to post process the cmake generated files and
remove all the absolute paths (since the project files are simply
text). Since cmake is a black box to me (and I am unfamiliar with it's
generated 'code'), it's unclear if this a 'good' ide
Hi Olivier,
I think you need to set the global property FIND_LIBRARY_USE_LIB64_PATHS
to OFF.
BTW, I disagree with Mathieu that building 32-bit libraries/executables
on a 64-bit system is cross-compilation. These binaries can be run
without a problem on the host system. So, IMHO, you don't need a
Mathieu Malaterre wrote:
> On Fri, Dec 4, 2009 at 4:39 PM, Olivier Pierard
> wrote:
>
>> Dear all,
>>
>> In order to perform 32 bits compilation on 64 bits platform, how can I
>> tell that all find_libraries for which no path is specified to look in
>> /usr/lib instead of /usr/lib64 ? Is there
50 matches
Mail list logo
