date:20091207

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
> accordingly.

The problem you were having is you were moc'ing files twice[*],
therefore the linker found two references to the very same methods,
one generated by automoc, the other generated by qt4_wrap_cpp.

[*] Assuming you had not cleaned your build directory

> I was trying to see if there was a way I could build the example without
> splitting the object def in main.cpp into main.h... but I guess not. So,
> this is a minor difference between CMake and qmake. In qmake its OK to have
> your object definitions in your source files, but it seems in CMake there's
> no way to do this cleanly.

There is. It's called QT4_AUTOMOC. Try the example I attached to the bugreport.

> Yes, I understand what you're saying about the bug with QT4_AUTOMOC... And
> the header not existing at all is a similar case to the header and src being
> in different directories.

You don't need to split .h and .cpp if you use QT4_AUTOMOC but until
the bug is fixed (sorry Clinton, I don't have time at the moment to
fix it), QT4_AUTOMOC will only work if .h and .cpp files are in the
same directory.

>
> Cheers
> Glenn
>
> On Mon, Dec 7, 2009 at 6:08 PM, Pau Garcia i Quiles 
> wrote:
>>
>> If you use QT4_WRAP_CPP, do not #include "blah.moc"
>>
>> If you use QT4_AUTOMOC, #include "blah.moc"
>>
>> QT4_AUTOMOC is more convenient but currently there's the bug I pointed
>> in my other e-mail: if the .h and the .cpp file for a class are in
>> different directories, QT4_AUTOMOC fails.
>>
>> --
>> Pau Garcia i Quiles
>> http://www.elpauer.org
>> (Due to my workload, I may need 10 days to answer)
>
>



-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] question about QT4_WRAP_CPP

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 way to get dependencies set up
> correctly is to add the MOC output to the target, i.e.
>
> QT4_WRAP_CPP( states_MOC_files ${states_HEADERS})
> ADD_EXECUTABLE( states MACOSX_BUNDLE ${states_SRCS} ${states_MOC_files}
> ${states_RESOURCES_SOURCES} )
>
> However, if I do this CMake adds the moc files (named in the form
> moc_foo.cxx) to the project to be compiled as C++ files.
> BUT, MOC files are not designed to be compiled on their own. Typically they
> are included at the bottom of the module that contains the source for the
> objects in question. They do not include all the headers that they need, and
> so they will not build independently.
>
> So, if I include the moc files in the ADD_EXECUTABLE line, my build doesn't
> work...
> but if I remove them, the dependency is not set up, so the moc files are not
> generated at all.
>
> How can I say "these files are required by this target, but don't try to
> compile them directly?"
>
> Or is there something else I should be doing?

If you use QT4_WRAP_CPP, do not #include "blah.moc"

If you use QT4_AUTOMOC, #include "blah.moc"

QT4_AUTOMOC is more convenient but currently there's the bug I pointed
in my other e-mail: if the .h and the .cpp file for a class are in
different directories, QT4_AUTOMOC fails.

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] question about QT4_WRAP_CPP

2009-12-07 Thread Glenn Hughes

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 to the target, i.e.

QT4_WRAP_CPP( states_MOC_files ${states_HEADERS})
ADD_EXECUTABLE( states MACOSX_BUNDLE ${states_SRCS} ${states_MOC_files}
${states_RESOURCES_SOURCES} )

However, if I do this CMake adds the moc files (named in the form
moc_foo.cxx) to the project to be compiled as C++ files.
BUT, MOC files are not designed to be compiled on their own. Typically they
are included at the bottom of the module that contains the source for the
objects in question. They do not include all the headers that they need, and
so they will not build independently.

So, if I include the moc files in the ADD_EXECUTABLE line, my build doesn't
work...
but if I remove them, the dependency is not set up, so the moc files are not
generated at all.

How can I say "these files are required by this target, but don't try to
compile them directly?"

Or is there something else I should be doing?

Thanks in advance
Glenn
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Copying cmake generated files to another machine

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 works, that's good. Proceed to
>> write a script for automating the absolute->relative path conversion.
>
> You are wasting your time.
>
> It's not going to be that easy. You will need to replace all the calls
> to CMake with generated stuff. Even in the improbable case you
> succeed, you would be giving people something which somewhat works,
> you would not be shipping the actual buildsystem but some kind of a
> pseudo-pre-geneated buildsystem.

You are right.

> Morale: anal retentive people must learn that opening your ass to
> something new may make you happier.

It is not so easy. Anal retentive people have the right personality
traits for doing QA and certification work.

-- 
Óscar

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Copying cmake generated files to another machine



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, CMake is really required for a variety of reasons.


Bummer. I completely forgot about this.

Steve, ditch the idea about the absolute->relative path conversion.


This is exactly the type of information I was looking for. I really  
didn't want us to spin our wheels on a dead end solution.


Thanks to everyone on the cmake list that helped me understand the  
constraints.


You really need to distribute CMake with the LLVM/clang sources,  
either as
source or as binary, and add a .bat for bootstrapping the thing. Is  
that

acceptable for your clients?



We will figure something out:-)

Thanks Oscar!

snaroff


[snip]

--
Óscar

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] can't link simple qt example

> 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 around it.

That's probably related to this bug:

http://public.kitware.com/Bug/view.php?id=9955

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Copying cmake generated files to another machine

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.

Bummer. I completely forgot about this.

Steve, ditch the idea about the absolute->relative path conversion. You
really need to distribute CMake with the LLVM/clang sources, either as
source or as binary, and add a .bat for bootstrapping the thing. Is that
acceptable for your clients?

[snip]

-- 
Óscar

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] can't link simple qt example

2009-12-07 Thread Glenn Hughes

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 macros
FIND_PACKAGE(Qt4 REQUIRED) # find and setup Qt4 for this project
INCLUDE(${QT_USE_FILE})

#set up src and rsrc variables
SET( states_SRCS main.cpp )
SET( states_RESOURCES states.qrc )

#generate moc dependencies, generate "resources as compiled binary data"
files
QT4_AUTOMOC(${states_SRCS})
QT4_ADD_RESOURCES( states_RESOURCES_SOURCES ${states_RESOURCES} )

#the moc files will be generated into the binary directory.
#Add this to the include search path so #include "main.moc" will work
INCLUDE_DIRECTORIES( ${CMAKE_BINARY_DIR} )

#make an executable target, and associate its sources, and declare what
external libraries its depends on
ADD_EXECUTABLE( states MACOSX_BUNDLE ${states_SRCS}
${states_RESOURCES_SOURCES} )
TARGET_LINK_LIBRARIES(states ${QT_LIBRARIES})
 ---

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 around it.

Cheers
G

On Fri, Dec 4, 2009 at 8:59 PM, Glenn Hughes  wrote:

> Hello all, I'm just getting going with CMake and qt, and I'm having a bit
> of a problem.
> I've assembled pretty much the simplest CMakeLists.txt file I can imagine
> for a very simple example qt project. (I'm trying to build the qt 4.6
> "states" example using CMake.)
>
> When I build, I get the following link errors:
>
> /usr/bin/ld: warning suggest use of -bind_at_load, as lazy binding may
> result in errors or different symbols being used
> /usr/bin/ld: Undefined symbols:
> qInitResources_states()
> /Developer/Examples/Qt/animation/states/states.build/Debug/states.build/Objects-normal/i386/main.o
> reference to undefined qInitResources_states()
> symbol typeinfo for QFactoryInterfaceused from dynamic library
> /Developer/SDKs/MacOSX10.4u.sdk/Library/Frameworks/QtCore.framework/QtCore(single
> module) not from earlier dynamic library
> QtGui.framework/Versions/4/QtGui(single module)
> symbol typeinfo for QEventTransitionPrivateused from dynamic library
> /Developer/SDKs/MacOSX10.4u.sdk/Library/Frameworks/QtCore.framework/QtCore(single
> module) not from earlier dynamic library
> QtGui.framework/Versions/4/QtGui(single module)
> symbol typeinfo for QAbstractItemModelPrivateused from dynamic library
> /Developer/SDKs/MacOSX10.4u.sdk/Library/Frameworks/QtCore.framework/QtCore(single
> module) not from earlier dynamic library
> QtGui.framework/Versions/4/QtGui(single module)
> symbol typeinfo for QAbstractEventDispatcherPrivateused from dynamic
> library
> /Developer/SDKs/MacOSX10.4u.sdk/Library/Frameworks/QtCore.framework/QtCore(single
> module) not from earlier dynamic library
> QtGui.framework/Versions/4/QtGui(single module)
> symbol typeinfo name for QFactoryInterfaceused from dynamic library
> /Developer/SDKs/MacOSX10.4u.sdk/Library/Frameworks/QtCore.framework/QtCore(single
> module) not from earlier dynamic library
> QtGui.framework/Versions/4/QtGui(single module)
> symbol typeinfo name for QEventTransitionPrivateused from dynamic library
> /Developer/SDKs/MacOSX10.4u.sdk/Library/Frameworks/QtCore.framework/QtCore(single
> module) not from earlier dynamic library
> QtGui.framework/Versions/4/QtGui(single module)
> symbol typeinfo name for QAbstractItemModelPrivateused from dynamic library
> /Developer/SDKs/MacOSX10.4u.sdk/Library/Frameworks/QtCore.framework/QtCore(single
> module) not from earlier dynamic library
> QtGui.framework/Versions/4/QtGui(single module)
> symbol typeinfo name for QAbstractEventDispatcherPrivateused from dynamic
> library
> /Developer/SDKs/MacOSX10.4u.sdk/Library/Frameworks/QtCore.framework/QtCore(single
> module) not from earlier dynamic library
> QtGui.framework/Versions/4/QtGui(single module)
> symbol vtable for QFactoryInterfaceused from dynamic library
> /Developer/SDKs/MacOSX10.4u.sdk/Library/Frameworks/QtCore.framework/QtCore(single
> module) not from earlier dynamic library
> QtGui.framework/Versions/4/QtGui(single module)
> symbol vtable for QEventTransitionPrivateused from dynamic library
> /Developer/SDKs/MacOSX10.4u.sdk/Library/Frameworks/QtCore.framework/QtCore(single
> module) not from earlier dynamic library
> QtGui.framework/Versions/4/QtGui(single module)
> symbol vtable for QAbstractItemModelPrivateused from dynamic library
> /Developer/SDKs/MacOSX10.4u.sdk/Library/Frameworks/QtCore.framework/QtCore(single
> module) not from earlier dynamic library
> QtGui.framework/Versions/4/QtGui(single module)
> symbol vtable for QAbstractEventDispatcherPrivateused from dynamic library
> /Developer/SDKs/MacOSX10.4u.sdk/Library/Frameworks/QtCore.framework/Qt

Re: [CMake] Copying cmake generated files to another machine

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
>> generated 'code'), it's unclear if this a 'good' idea? Or will I bump
>> into other gotcha's?
>
> I suggested that option to you on the past.
>
> My guess is that the VS project files generated by CMake depends less on
> absolute paths than the Makefiles generated for other build
> systems. Building in-source maybe diminishes the amount of work too.
>
> As LLVM/clang have no external dependencies, the problem is simpler. If
> VS is installed on C: and the LLVM source and build directories are on
> C: too, the problem is even simpler, because you can always replace an
> absolute path with a relative one.
>
> 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 works, that's good. Proceed to
> write a script for automating the absolute->relative path conversion.

You are wasting your time.

It's not going to be that easy. You will need to replace all the calls
to CMake with generated stuff. Even in the improbable case you
succeed, you would be giving people something which somewhat works,
you would not be shipping the actual buildsystem but some kind of a
pseudo-pre-geneated buildsystem.

Morale: anal retentive people must learn that opening your ass to
something new may make you happier.

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Copying cmake generated files to another machine

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 will I bump
> into other gotcha's?

I suggested that option to you on the past.

My guess is that the VS project files generated by CMake depends less on
absolute paths than the Makefiles generated for other build
systems. Building in-source maybe diminishes the amount of work too.

As LLVM/clang have no external dependencies, the problem is simpler. If
VS is installed on C: and the LLVM source and build directories are on
C: too, the problem is even simpler, because you can always replace an
absolute path with a relative one.

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 works, that's good. Proceed to
write a script for automating the absolute->relative path conversion.

> Any advice is appreciated...you have a lot more experience with this
> than I do!

Nor really. I investigated a bit when you asked but found essentially
what Eric and Brad explained on this thread. 

-- 
Óscar

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Copying cmake generated files to another machine

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 scratch?
> It's do-able, but the effort is much greater than installing CMake.
>
> If there is any reason not to install CMake other than "it's another
> dependency", perhaps we can address it.  If the only reason is that
> "it's another dependency", consider that once CMake is installed it
> can find all the *other* dependencies automatically on most systems.

My knowledge about Steve's circumstance is just a bit more detailed than
what he exposed here, but I have experience on even stricter
environments and can explain how the thing goes:

A department's work is to certify some piece of software for some
purpose (release to the public, internal use, etc). They have the source
code (LLVM/clang, on this case) and hence they need a compiler
(VC++). LLVM/clang has no external dependencies, it only uses the system
libraries. So adding CMake to the requirements is to add a dependency
where none was required before.

The people who do that kind of work is very strict ("anal retentive" if
you prefer) and will resist any change on their work routine.

If Steve sneaks CMake's source code with the LLVM/clang source base and
adds a script for building the whole package, maybe the "clients" will
not care. If he adds installing CMake and invoking it for generating the
VC++ project files, it is very likely that he will find a strong
resistance.

-- 
Óscar

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Copying cmake generated files to another machine

2009-12-07 Thread Alexander Neundorf

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
> generated 'code'), it's unclear if this a 'good' idea? Or will I bump
> into other gotcha's?

Possibly (at least you would if this was for KDE).
In KDEs build files cmake itself is also called from the makefiles, not only 
for generating makefiles, but also e.g. to execute scripts, copy files, 
create directories, and other things we are otherwise not portable between 
different OSs.
With "cmake -E" you can do such things in a portable way, or you can run 
simple scripts via "cmake -p", in both cases embedded as COMMAND in 
add_custom_target() or add_custom_command().

Also, cmake itself is used for generating the C dependencies. I don't know 
what happens if you don't have cmake around.

So, as the others say, consider cmake a part of the toolchain which must be 
installed on the building host.

Alex
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Idea - Modules development and management

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 signed off by kitware) to be updated at a
> more rapid pace than CMake itself.

The question is, would you update CMake itself or would you do it on
a per-project basis? In the first case this is the administrator job
whereas in the second case the "project admin" may chose to "cache"
updated CMake module (official or unofficial) in its project source tree.

> The first iteration could just be a
> "check a website" type of deal. The next iteration would be something akin
> to a scheduled update type of thing. Again, some one would have to find the
> time to implement such a feature, plus setup the infrastructure internet
> stuff and all that, but might be very worthwhile in the long run.

I recover a past thread with similar discussion:
see for example
http://www.cmake.org/pipermail/cmake/2009-February/027087.html
and
http://www.cmake.org/pipermail/cmake/2009-February/027145.html


-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Copying cmake generated files to another machine

2009-12-07 Thread Bill Hoffman

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.txt file changed, it is used for other things as well.  It is 
used to output in color and for cmake -E commands such as copy.  So, the 
generated makefiles are not really independent and the relative paths 
would not remove any of the other dependencies I just mentioned.


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.  However, the only 
requirement for CMake is a C++ compiler.  CMake itself bootstraps on any 
unix platform.  It can run from any directory (no root needed to 
install).  Binaries are provided for all major platforms as well. It is 
in the grand scheme of things a very small dependency.


-Bill
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Idea - Modules development and management

2009-12-07 Thread Michael Jackson



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 ideas
in order to see past pro- and cons- the main idea.


  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 point to an  
updated
Module path (note : I am referring to a complete Module including  
everything

that was originally ship with a given version of CMake, plus updates)


I think you could already do that now.
If you
SET(CMAKE_MODULE_PATH /your/prefered/path)
in your CMakeLists.txt

then CMake will look in there first.


--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org



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 signed off  
by kitware) to be updated at a more rapid pace than CMake itself. The  
first iteration could just be a "check a website" type of deal. The  
next iteration would be something akin to a scheduled update type of  
thing. Again, some one would have to find the time to implement such a  
feature, plus setup the infrastructure internet stuff and all that,  
but might be very worthwhile in the long run.


_
Mike Jackson  mike.jack...@bluequartz.net
BlueQuartz Softwarewww.bluequartz.net
Principal Software Engineer  Dayton, Ohio

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Copying cmake generated files to another machine

2009-12-07 Thread Michael Wild



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 compiler and the linker. We did that at work  
and
it's no big deal, people are so happy with the pro's of CMake  
over our
former buildsystem (Visual C++ projects for Windows and Makefiles  
for
Unix, which required twice the amount of maintainance work), they  
are

not looking back.



As I said in my initial post, we love CMake for development (since
llvm/clang are cross platform). Developers understand the benefits  
of

'cmake'. Unfortunately, developers aren't the only clients building
llvm/clang.


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 to trust me on this - llvm/clang is being deployed within  
organizations that don't have cmake installed (and don't want to add  
it to their list of dependencies).


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 list of reasons why relative paths are so hard for cmake  
to cope with (from one of the lead developers, if possible). If I  
understood more of the technical rationale, I'd likely be more  
sympathetic to the limitation (and apparent desire to deprecate the  
feature entirely).


Thanks for your engagement on this topic,

snaroff



May be the solution would be to propose the compiler vendor to  
include
CMake in its product, that way they would get CMake "out-of-the- 
box" :-)



In any event, maybe adding CMake to our build chain isn't such a  
big deal.


Just trying to get the collective wisdom of this group before we  
make any

changes.


Like Pau said I think that if CMake developer (like Bill) do advise
to give up "relative path" they must be thinking that with good  
reason.


You are right too, the range of cross-portability targeted by CMake
and by llvm/clang may not be the same, and "may be" you can  
constrain yourself

with a subset of CMake current features which makes it possible to do
what you want:
no CMake use after first generation, only relative path.

After that, the question is, is the seeked goal worth the [CMake]
feature you loose?



Honestly, CMake is no big deal. You don't have to "install" CMake in  
the traditional sense (like in /usr/bin or /usr/local/bin, or  
wherever). You can either download a binary version from www.cmake.org  
or build one yourself, and just dump it into anyplace you like.


I could imagine that something like the following works for you:

- you distribute a pure source-tarball
- included are instructions (and possibly a script) to fetch a  
prebuilt CMake
  (if not installed already) and put it in a special place in the  
source tree
- use a script to drive CMake, possibly using the -C flag to  
initialize the cache


Once llvm/clang is built and installed, people can dispose of the  
binary tree and the source tree, removing all traces of CMake.


Michael
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Idea - Modules development and management

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 idea.

>   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 point to an updated
> Module path (note : I am referring to a complete Module including everything
> that was originally ship with a given version of CMake, plus updates)

I think you could already do that now.
If you
 SET(CMAKE_MODULE_PATH /your/prefered/path)
in your CMakeLists.txt

then CMake will look in there first.


-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] FindQT4 documentation?

2009-12-07 Thread Clinton Stimpson

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.html#module:FindQt4

That text is found within the FindQt4.cmake file, and is the source for the 
online documentation.

Clint

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] FindQT4 documentation?

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.org
(Due to my workload, I may need 10 days to answer)
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] FindQT4 documentation?

2009-12-07 Thread Glenn Hughes

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 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Idea - Modules development and management

2009-12-07 Thread Nicholas Yue


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 point to an 
updated Module path (note : I am referring to a complete Module 
including everything that was originally ship with a given version of 
CMake, plus updates)


Regards

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Patch to FindFreetype.cmake to avoid NOTFOUND in FREETYPE_LIBRARIES

2009-12-07 Thread Rothganger, Fredrick

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_LIBRARIES variable in an IF(XXX_FOUND) block.  
This reduces the complexity of specifying which libraries to link a target 
against when that list contains optional libraries.  Attached is a patch that 
modifies FindFreetype to follow this convention as well.  Please consider 
making this change.

-- Fred



FindFreetype.diff
Description: FindFreetype.diff
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Build only what you need in third party libs

2009-12-07 Thread troy d. straszheim

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.resophonic.com/boost-cmake/current-docs/exported_targets.html#with-boost-source-in-a-subdirectory-of-your-source

the EXCLUDE_FROM_ALL option to add_subdirectory makes things
remarkably easy... nice feature.

-t

Nice,
Couple of comments though:
"Setting BUILD_PROJECTS, etc is unnecessary, but if all the extra boost
targets bother you you can set it at the commandline as usual:"

Why can't I set BUILD_PROJECTS in my own CMakeLists.txt file? Wouldn't
this get rid of the need to pass this on the command line? Also what
about those running CMake-GUI? They don't have a command line to work from?

Yup, you can, it needs to be CACHE STRING FORCE.

By using the name of the target (boost_filesystem-mt-shared in your
example), will CMake automatically "do the right thing" with respect to
Debug and release libraries? Will building my project as a Debug pick up
the Debug Boost libraries?

No, boost-cmake doesn't play nice with this kind of thing. In the
beginning we were attempting to do things the way bjam does them,
compiling all variants with one command. In retrospect I think this was
a really bad idea. Now things clash, and it would be major surgery to
fix... major surgery that I may yet do, but realize that it would break
a growing amount of code that depends on the way boost-cmake now does
things. :(

You could check CMAKE_BUILD_TYPE and tweak the name that you're linking
against:

if (CMAKE_BUILD_TYPE STREQUAL Debug)
set(DBG_OR_RELEASE "-debug")
endif()

target_link_libraries(mything boost_filesystem-mt-shared${DBG_OR_RELEASE})

I see this as having some issues? I now have to detect when someone
wants a "Debug" build then set the "BOOST_ENABLE_DEBUG=ON" before
calling the add_subdirectory(boost-src).

If you just let boost.cmake configure all the targets, use
EXCLUDE_FROM_ALL and tweak the name you link to above, only what you
need gets built, and your CMAKE_BUILD_TYPE works as you expect it to.
The same name-tweaking above will work if you use exported targets
instead of boost-src-in-subdirectory.

I say all this without having tried any of this but it _is_ intriguing
me currently due to all the problems trying to get Boost built OS X and
Windows without memory leaks, compile errors and, ya know, basic stuff
like that. If I can have my own patched version of boost in my project
this may save some serious head aches in the future.

And on the boost-cmake list we should talk about what those patches
would be. You're not the only one doing this, and we have the capacity
to do point releases of boost asynchronously from upstream.

-t

___
Powered by www.kitware.com

Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Build only what you need in third party libs

2009-12-07 Thread Michael Jackson

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-cmake/current-docs/exported_targets.html#with-boost-source-in-a-subdirectory-of-your-source

the EXCLUDE_FROM_ALL option to add_subdirectory makes things
remarkably easy... nice feature.

-t

Nice,
Couple of comments though:
"Setting BUILD_PROJECTS, etc is unnecessary, but if all the extra
boost targets bother you you can set it at the commandline as usual:"

By using the name of the target (boost_filesystem-mt-shared in your
example), will CMake automatically "do the right thing" with respect
to Debug and release libraries? Will building my project as a Debug
pick up the Debug Boost libraries?

I see this as having some issues? I now have to detect when someone
wants a "Debug" build then set the "BOOST_ENABLE_DEBUG=ON" before
calling the add_subdirectory(boost-src).

I say all this without having tried any of this but it _is_
intriguing me currently due to all the problems trying to get Boost
built OS X and Windows without memory leaks, compile errors and, ya
know, basic stuff like that. If I can have my own patched version of
boost in my project this may save some serious head aches in the future.

Mike Jackson
___
Powered by www.kitware.com

Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Copying cmake generated files to another machine

2009-12-07 Thread Brad King

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
list of reasons why relative paths are so hard for cmake to cope with
(from one of the lead developers, if possible).

In principle you are correct...with enough effort the build system
that CMake generates could use relative paths to refer to the source
tree from the build tree in the common case. It's not easy...there are
a lot of places that paths appear. Some of them are mentioned in the
user-maintained FAQ:

http://www.cmake.org/Wiki/CMake_FAQ#Why_does_CMake_use_full_paths.2C_or_can_I_copy_my_build_tree.3F

The answer there could use some refinement, but it is generally correct.

We support "out-of-source source" where a source tree from somewhere
outside the main source tree on disk is given to add_subdirectory()
by a full path. Perhaps if it were given as a relative path then we
could honor that too, but that is also more effort.

However, the above-mentioned effort is not worthwhile in our opinion
because relative/full path issues are not the only reason that CMake
does not generate redistributable build files. CMake build trees
have a lot of *stateful* per-machine information in the CMakeCache.txt
and a few other files, including the following:

- Full path to the compiler(s), and compiler vendor identification
- Target architecture properties (32-bit v. 64-bit, etc.)
- Results from try-compile tests
- Results from find_program, find_library, and other search commands

Much of this information is needed to support system introspection
features, which is one of the features that makes CMake so powerful.
Initializing and maintaining it requires CMake to be installed on
the build machine.

It is possible to relocate build trees if all of the above stateful
information remains valid in the new locations. By the time that
happens, the new locations are so similar to the old location that
you might as well distribute a pre-compiled binary.

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 scratch?
It's do-able, but the effort is much greater than installing CMake.

If there is any reason not to install CMake other than "it's another
dependency", perhaps we can address it. If the only reason is that
"it's another dependency", consider that once CMake is installed it
can find all the *other* dependencies automatically on most systems.

-Brad
___
Powered by www.kitware.com

Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Copying cmake generated files to another machine

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 to
> trust me on this - llvm/clang is being deployed within organizations that
> don't have cmake installed (and don't want to add it to their list of
> dependencies).

I do trust you, no problem !!
I was just [technically] curious :-)

> 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 list of
> reasons why relative paths are so hard for cmake to cope with (from one of
> the lead developers, if possible). If I understood more of the technical
> rationale, I'd likely be more sympathetic to the limitation (and apparent
> desire to deprecate the feature entirely).

I let appropriate people answer that one.
I have not sufficient knowledge to answer.

> Thanks for your engagement on this topic,

You are welcome.
-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Build only what you need in third party libs

2009-12-07 Thread troy d. straszheim


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-in-a-subdirectory-of-your-source

the EXCLUDE_FROM_ALL option to add_subdirectory makes things remarkably 
easy... nice feature.


-t


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Copying cmake generated files to another machine



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 big deal, people are so happy with the pro's of CMake over  
our
former buildsystem (Visual C++ projects for Windows and Makefiles  
for
Unix, which required twice the amount of maintainance work), they  
are

not looking back.



As I said in my initial post, we love CMake for development (since
llvm/clang are cross platform). Developers understand the benefits of
'cmake'. Unfortunately, developers aren't the only clients building
llvm/clang.


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 to trust me on this - llvm/clang is being deployed within  
organizations that don't have cmake installed (and don't want to add  
it to their list of dependencies).


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  
list of reasons why relative paths are so hard for cmake to cope with  
(from one of the lead developers, if possible). If I understood more  
of the technical rationale, I'd likely be more sympathetic to the  
limitation (and apparent desire to deprecate the feature entirely).


Thanks for your engagement on this topic,

snaroff



May be the solution would be to propose the compiler vendor to include
CMake in its product, that way they would get CMake "out-of-the- 
box" :-)



In any event, maybe adding CMake to our build chain isn't such a  
big deal.


Just trying to get the collective wisdom of this group before we  
make any

changes.


Like Pau said I think that if CMake developer (like Bill) do advise
to give up "relative path" they must be thinking that with good  
reason.


You are right too, the range of cross-portability targeted by CMake
and by llvm/clang may not be the same, and "may be" you can  
constrain yourself

with a subset of CMake current features which makes it possible to do
what you want:
no CMake use after first generation, only relative path.

After that, the question is, is the seeked goal worth the [CMake]
feature you loose?


--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Build only what you need in third party libs

2009-12-07 Thread Michael Jackson

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_system;system

# Configure the Boost CMake distribution to build
add_subdirectory(boost-cmake0 ${PROJECT_BINARY_DIR}/Boost-Cmake0)

# look at  for
# more details about the included file. Assuming it is already  
generated by the time cmake

# hits this point.
include (  ${PROJECT_BINARY_DIR}/Boost-Cmake0/lib/Exports.cmake )

# Create your executable
add_executable(my_exe ${my_exe_sources} )
# Have your executable link to the boost-file_system library (and  
probably the boost-system library)
# Note that the 'boost_file_system' is the actual name of a target  
from the Boost-cmake0 sub project.

#  See the web page linked above for more details
target_link_libraries ( my_exe boost_file_system)

I have not tried this at all, but this would be my first attempt. The  
'target_link_libraries()' command will take care of all the  
dependencies for 'my_exe', thus making sure boost-file_system is built  
first before building the 'my_exe' executable.

Maybe someone else can comment..

_
Mike Jackson  mike.jack...@bluequartz.net
BlueQuartz Softwarewww.bluequartz.net
Principal Software Engineer  Dayton, Ohio

On Dec 7, 2009, at 11:47 AM, Brian Davis wrote:

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  
without namespace resolution within CMake (or is there already this  
problem or have I missed something)?

What I would like to do is set (please bear with me as I am a  
complete nube to CMake)

BUILD_PROJECTS=none

Then do

add_subdirectory(boost_source_dir)

project( my_exe )
add_executable( my_exe mysource.cpp )
add_library( boost_filesystem   SHARED)
#An IMPORTED library target references a library file located  
outside the project. No rules are generated to build it. <- Too bad  
about this last statement

or

add_dependencies( my_exe boost_filesystem )

Is there any mechanism for project level resolution of third party  
source targets such as in bjam boost//boost_filesystem

project
: requirements ../build//boost_filesystem
  /boost/system//boost_system
  true
;

project boost/filesystem
: source-location ../src
: usage-requirements # pass these requirement to dependents  
(i.e. users)

  shared:BOOST_FILESYSTEM_DYN_LINK=1
  static:BOOST_FILESYSTEM_STATIC_LINK=1
;

And boost_filesystem's use:

project
: requirements
  /boost/filesystem//boost_filesystem
  msvc:on
;

where some syntax like:

add_subdirectory(boost_source_dir PROJECT boost )

add_dependencies( my_exe boost//boost_filesystem )

or

add_library( boost//boost_filesystem   SHARED)

allowing the specification and namespace resolution of the 3rdParty  
(boost) library

I know above does not exist as my example question shows, but if it  
does in some other form what is it?

Brian

On Sat, Dec 5, 2009 at 3:45 PM, Mike Jackson > wrote:

I _think_ you _might_ be able to set the BUILD_PROJECTS to
"file_system;system" then do the "add_subdirectory()".
 Give it a shot and see what happens.

_
Mike Jackson  mike.jack...@bluequartz.net
BlueQuartz Softwarewww.bluequartz.net
Principal Software Engineer  Dayton, Ohio

On Sat, Dec 5, 2009 at 4:15 PM, Brian Davis   
wrote:

>
> I have used boost jam before and there was a mechanism to build  
only what
> you need by specifying dependencies within the boost libraries.   
bjam would
> then run off calculate deps and build only what I needed. In CMake  
is there
> such a feature to specify a third party library and specify only  
the targets

> you need to build as dependencies of my build target?
>
> i.e. can I use
>
> add_subdirectory( lib/3rdParty/Win32/boost-cmake-1_41_0 ./boost )
>
> then create a target that only uses say boost_filesystem and only  
have that
> built? Or do I need to build the world to get a handful of needed  
dll's that

> are actually used in my project?
>
> --
> Brian J. Davis
>
>
> ___
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubs

Re: [CMake] Newie's question: Multiple applications with one common kernel

2009-12-07 Thread Tyler Roscoe

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/libraries (external libraries)
> 
> Each application has some source files and uses the common source files
> from the kernel directory which is *not* a subdirectory. In a first
> attempt, I wrote one CMakeLists.txt file on the kernel directory which
> has a list of all kernel source files. Each application/appX directory
> has its own CMakeLists.txt file which includes the kernel sources via:
> 
> ADD_SUBDIRECTORY (${APPX_SOURCE_DIR}/../..
> ${CMAKE_CURRENT_BINARY_DIR}/kernel)
> 
> Unfortunately, the variables defined in the kernel's CMakeLists.txt file
> are not available from within the application's CMakeLists.txt file.

When you do add_subdirectory(), you create a new scope. The variables in
your kernel CMakeLists are set in that scope by default. Take a look at
the PARENT_SCOPE argument to set() to deal with this.

Another common approach to this sort of setup is to deal with all the
common kernel code in a top-level CMakeLists and then have that
top-level CMakeLists do the add_subdirectory() calls into each appX
subdirectory.

tyler
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Build only what you need in third party libs

2009-12-07 Thread Brian Davis

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  
without namespace resolution within CMake (or is there already this  
problem or have I missed something)?


What I would like to do is set (please bear with me as I am a complete  
nube to CMake)


BUILD_PROJECTS=none

Then do

add_subdirectory(boost_source_dir)

project( my_exe )
add_executable( my_exe mysource.cpp )
add_library( boost_filesystem   SHARED)
#An IMPORTED library target references a library file located outside  
the project. No rules are generated to build it. <- Too bad about this  
last statement


or

add_dependencies( my_exe boost_filesystem )


Is there any mechanism for project level resolution of third party  
source targets such as in bjam boost//boost_filesystem


project
: requirements ../build//boost_filesystem
  /boost/system//boost_system
  true
;


project boost/filesystem
: source-location ../src
: usage-requirements # pass these requirement to dependents (i.e.  
users)

  shared:BOOST_FILESYSTEM_DYN_LINK=1
  static:BOOST_FILESYSTEM_STATIC_LINK=1
;

And boost_filesystem's use:

project
: requirements
  /boost/filesystem//boost_filesystem
  msvc:on
;

where some syntax like:

add_subdirectory(boost_source_dir PROJECT boost )

add_dependencies( my_exe boost//boost_filesystem )

or

add_library( boost//boost_filesystem   SHARED)


allowing the specification and namespace resolution of the 3rdParty  
(boost) library


I know above does not exist as my example question shows, but if it  
does in some other form what is it?


Brian

On Sat, Dec 5, 2009 at 3:45 PM, Mike Jackson > wrote:

I _think_ you _might_ be able to set the BUILD_PROJECTS to
"file_system;system" then do the "add_subdirectory()".
 Give it a shot and see what happens.

_
Mike Jackson  mike.jack...@bluequartz.net
BlueQuartz Softwarewww.bluequartz.net
Principal Software Engineer  Dayton, Ohio



On Sat, Dec 5, 2009 at 4:15 PM, Brian Davis  wrote:
>
> I have used boost jam before and there was a mechanism to build  
only what
> you need by specifying dependencies within the boost libraries.   
bjam would
> then run off calculate deps and build only what I needed. In CMake  
is there
> such a feature to specify a third party library and specify only  
the targets

> you need to build as dependencies of my build target?
>
> i.e. can I use
>
> add_subdirectory( lib/3rdParty/Win32/boost-cmake-1_41_0 ./boost )
>
> then create a target that only uses say boost_filesystem and only  
have that
> built? Or do I need to build the world to get a handful of needed  
dll's that

> are actually used in my project?
>
> --
> Brian J. Davis
>
>
> ___
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>



--
Brian J. Davis

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Newie's question: Multiple applications with one common kernel

2009-12-07 Thread Matthias Moeller

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 (common kernel source files)

root/libraries (external libraries)


Each application has some source files and uses the common source files
from the kernel directory which is *not* a subdirectory. In a first
attempt, I wrote one CMakeLists.txt file on the kernel directory which
has a list of all kernel source files. Each application/appX directory
has its own CMakeLists.txt file which includes the kernel sources via:

ADD_SUBDIRECTORY (${APPX_SOURCE_DIR}/../..
${CMAKE_CURRENT_BINARY_DIR}/kernel)

Unfortunately, the variables defined in the kernel's CMakeLists.txt file
are not available from within the application's CMakeLists.txt file.


Any help on this problem will be appreciated.

Best regards,
Matthias Moeller

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake and OpenWrt

2009-12-07 Thread Tim Just


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 toolchain.cmake file and then use 
the produced Makefile during the openembedded respectively openwrt build 
process?


Do you have an usage example?

BR,

Tim



see: http://www.cmake.org/Wiki/CMake_Cross_Compiling


On Mon, Dec 7, 2009 at 4:05 PM, Tim Just > wrote:


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 effort to build our software using this combination.

Now I'm not sure if it is possible to use CMake as build system
within OpenWrt. The point is, that during the build process the
whole toolchain has to be compiled for the target platform...

My searches on google only produced [2].

Has anybody already used CMake in combination with OpenWrt or has
some ideas how to start?

Best regards,

Tim



[1] http://www.openwrt.org/
[2] https://dev.openwrt.org/ticket/3010
___
Powered by www.kitware.com 

Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake




___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake and OpenWrt

2009-12-07 Thread Cedric GESTES

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  wrote:

> 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
> effort to build our software using this combination.
>
> Now I'm not sure if it is possible to use CMake as build system within
> OpenWrt. The point is, that during the build process the whole toolchain has
> to be compiled for the target platform...
>
> My searches on google only produced [2].
>
> Has anybody already used CMake in combination with OpenWrt or has some
> ideas how to start?
>
> Best regards,
>
> Tim
>
>
>
> [1] http://www.openwrt.org/
> [2] https://dev.openwrt.org/ticket/3010
> ___
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CMake and OpenWrt

2009-12-07 Thread Tim Just


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 
effort to build our software using this combination.


Now I'm not sure if it is possible to use CMake as build system within 
OpenWrt. The point is, that during the build process the whole toolchain 
has to be compiled for the target platform...


My searches on google only produced [2].

Has anybody already used CMake in combination with OpenWrt or has some 
ideas how to start?


Best regards,

Tim



[1] http://www.openwrt.org/
[2] https://dev.openwrt.org/ticket/3010
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] continuous integration with CMake

2009-12-07 Thread Randy Hancock

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 xml is relatively straightforward
so if you had to administer it that way it would be doable. It's also
extremely simple to duplicate a configuration to another instance.

We're using ant to call our build scripts but that's a holdover from
cruisecontrol. Hudson will let you call any shell script. And yes, we
have the Chuck Norris plugin installed :)

  false

svn://host/myrepo/myproj/trunk
myproj

true

  true
  false
  false

  * * * * *

  false

  init version-rc-update dev-copy
  build-win32.xml

  cmake-with-vcproj build test
  storage/build.xml

  myproj/results/*storage*.txt
  false

  m...@mydomain.com
  false
  false

-randy

On Fri, Dec 4, 2009 at 11:40 AM, Tyler Roscoe  wrote:
> On Fri, Dec 04, 2009 at 09:00:14AM -0800, Tyler Roscoe wrote:
>> Thanks for the reply. I'm going to try to carve out some time to give
>> Hudson a test drive.
>
> Btw, Randy, are any of your Hudson configs or other setup scripts
> available somewhere for me to look at? Maybe you can send them to me
> off-list?
>
> Thanks,
> tyler
>
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Copying cmake generated files to another machine

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 of CMake over our
>> former buildsystem (Visual C++ projects for Windows and Makefiles for
>> Unix, which required twice the amount of maintainance work), they are
>> not looking back.
>>
>
> As I said in my initial post, we love CMake for development (since
> llvm/clang are cross platform). Developers understand the benefits of
> 'cmake'. Unfortunately, developers aren't the only clients building
> llvm/clang.

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?


May be the solution would be to propose the compiler vendor to include
CMake in its product, that way they would get CMake "out-of-the-box" :-)


> In any event, maybe adding CMake to our build chain isn't such a big deal.
>
> Just trying to get the collective wisdom of this group before we make any
> changes.

Like Pau said I think that if CMake developer (like Bill) do advise
to give up "relative path" they must be thinking that with good reason.

You are right too, the range of cross-portability targeted by CMake
and by llvm/clang may not be the same, and "may be" you can constrain yourself
with a subset of CMake current features which makes it possible to do
what you want:
no CMake use after first generation, only relative path.

After that, the question is, is the seeked goal worth the [CMake]
feature you loose?


-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] 32 bits compilation on x64 platform - how to find system libraries

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_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
> >>> toolchain file. The only thing you have to do is instruct gcc/g++ to
> >>> generate 32-bit objects/binaries, using the -m32 option, and tell CMake
> >>> to look in lib instead of lib64 by setting the aforementioned property.
> >>>   
> >> There is two things from the top of my head:
> >> 1. ia64 which is not x86 compatible
> >> 2. You still need a libz/libpng/libjpeg compiled as 32bits on your
> >> amd64 system...
> >>
> >> I think the project needs to be self contained (convenient libs)
> >> otherwise to get it compiled using the -m32 trick
> >>
> >> 2cts
> >> 
> >
> > Hi Mathieu
> >
> > Indeed, ia64 is not x86 compatible. I thought that Olivier was using a
> > x86_64 processor. Most 64-bit distros (for x86_64 that is) also provide
> > 32-bit libs/binaries.
> >   
> Thanks guys for your insights.  I'm effectively working on a x86_64 with
> 32-bits pre-compiled libs provided by Suse in folder /usr/lib/ while
> 64-bits libraries are in /usr/lib64/.
> 
> Solution proposed by Marcel seemed perfectly suitable for me.  So I tried:
> set(FIND_LIBRARY_USE_LIB64_PATHS OFF)
> ...
> find_library(FLTK_LIB_TEST NAMES fltk)
> message(FIND_LIBRARY_USE_LIB64_PATHS: ${FIND_LIBRARY_USE_LIB64_PATHS})
> message(FLTK_LIB_TEST: ${FLTK_LIB_TEST})
> 
> And with 'cmake -U "*LIB*" ..', I get:
> FIND_LIBRARY_USE_LIB64_PATHS:OFF
> FLTK_LIB_TEST:/usr/lib64/libfltk.a
> 
> Of course, libfltk.a is well in both folders /usr/lib/ and /usr/lib64/.
> 
> Olivier
> > Best regards,
> > Marcel Loose.
> >
> >
> >
> >

Hi Olivier,

FIND_LIBRARY_USE_LIB64_PATHS is a property. Set it like this:

  set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS OFF)

If you do, you'll see that CMake will find /usr/lib/libfltk.a.

Best regards,
Marcel Loose.


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] [Fwd: FindHDF5 bug: HDF5_FOUND is not set]

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.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.


--- End Message ---
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Copying cmake generated files to another machine



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
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 will I bump into other  
gotcha's?


Any advice is appreciated...you have a lot more experience with  
this than I

do!


Steve, if that was a good idea, CMake would be doing that by default
instead of using absolute paths, don't you think?



Sure, but any cross platform tool has the constraint that it needs to  
deal with the "lowest common denominator" (which might be difficult).


As a result, it could be the case that using relative paths for Visual  
Studio (just to take an example) might be simpler than using relative  
paths when generating Unix 'make' files.



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 of CMake over our
former buildsystem (Visual C++ projects for Windows and Makefiles for
Unix, which required twice the amount of maintainance work), they are
not looking back.



As I said in my initial post, we love CMake for development (since  
llvm/clang are cross platform). Developers understand the benefits of  
'cmake'. Unfortunately, developers aren't the only clients building  
llvm/clang.


In any event, maybe adding CMake to our build chain isn't such a big  
deal.


Just trying to get the collective wisdom of this group before we make  
any changes.


Thanks for your input,

snaroff


--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] 32 bits compilation on x64 platform - how to find system libraries

2009-12-07 Thread Olivier Pierard

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 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
>>> toolchain file. The only thing you have to do is instruct gcc/g++ to
>>> generate 32-bit objects/binaries, using the -m32 option, and tell CMake
>>> to look in lib instead of lib64 by setting the aforementioned property.
>>>   
>> There is two things from the top of my head:
>> 1. ia64 which is not x86 compatible
>> 2. You still need a libz/libpng/libjpeg compiled as 32bits on your
>> amd64 system...
>>
>> I think the project needs to be self contained (convenient libs)
>> otherwise to get it compiled using the -m32 trick
>>
>> 2cts
>> 
>
> Hi Mathieu
>
> Indeed, ia64 is not x86 compatible. I thought that Olivier was using a
> x86_64 processor. Most 64-bit distros (for x86_64 that is) also provide
> 32-bit libs/binaries.
>   
Thanks guys for your insights.  I'm effectively working on a x86_64 with
32-bits pre-compiled libs provided by Suse in folder /usr/lib/ while
64-bits libraries are in /usr/lib64/.

Solution proposed by Marcel seemed perfectly suitable for me.  So I tried:
set(FIND_LIBRARY_USE_LIB64_PATHS OFF)
...
find_library(FLTK_LIB_TEST NAMES fltk)
message(FIND_LIBRARY_USE_LIB64_PATHS: ${FIND_LIBRARY_USE_LIB64_PATHS})
message(FLTK_LIB_TEST: ${FLTK_LIB_TEST})

And with 'cmake -U "*LIB*" ..', I get:
FIND_LIBRARY_USE_LIB64_PATHS:OFF
FLTK_LIB_TEST:/usr/lib64/libfltk.a

Of course, libfltk.a is well in both folders /usr/lib/ and /usr/lib64/.

Olivier
> Best regards,
> Marcel Loose.
>
>
>
>
>   


-- 
Olivier Pierard

CENAERO, Virtual Manufacturing Group

Bâtiment EOLE, 1er étage
Rue des Frères Wright, 29
B-6041 Gosselies
BELGIUM 

Tel: +32.(0)71.919374
Fax: +32.(0)71.919370

http://www.cenaero.be/

+-+-+- Disclaimer +-+-+-

http://www.cenaero.be/disclaimer

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Copying cmake generated files to another machine

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's generated 'code'),
> it's unclear if this a 'good' idea? Or will I bump into other gotcha's?
>
> Any advice is appreciated...you have a lot more experience with this than I
> do!

Steve, if that was a good idea, CMake would be doing that by default
instead of using absolute paths, don't you think?

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 of CMake over our
former buildsystem (Visual C++ projects for Windows and Makefiles for
Unix, which required twice the amount of maintainance work), they are
not looking back.

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] FindHDF5 bug: HDF5_FOUND is not set

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.


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] 32 bits compilation on x64 platform - how to find system libraries

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/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
> > toolchain file. The only thing you have to do is instruct gcc/g++ to
> > generate 32-bit objects/binaries, using the -m32 option, and tell CMake
> > to look in lib instead of lib64 by setting the aforementioned property.
> 
> 
> There is two things from the top of my head:
> 1. ia64 which is not x86 compatible
> 2. You still need a libz/libpng/libjpeg compiled as 32bits on your
> amd64 system...
> 
> I think the project needs to be self contained (convenient libs)
> otherwise to get it compiled using the -m32 trick
> 
> 2cts

Hi Mathieu

Indeed, ia64 is not x86 compatible. I thought that Olivier was using a
x86_64 processor. Most 64-bit distros (for x86_64 that is) also provide
32-bit libs/binaries.

Best regards,
Marcel Loose.


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] 32 bits compilation on x64 platform - how to find system libraries

2009-12-07 Thread Mathieu Malaterre

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
> without a problem on the host system. So, IMHO, you don't need a
> toolchain file. The only thing you have to do is instruct gcc/g++ to
> generate 32-bit objects/binaries, using the -m32 option, and tell CMake
> to look in lib instead of lib64 by setting the aforementioned property.


There is two things from the top of my head:
1. ia64 which is not x86 compatible
2. You still need a libz/libpng/libjpeg compiled as 32bits on your
amd64 system...

I think the project needs to be self contained (convenient libs)
otherwise to get it compiled using the -m32 trick

2cts
-- 
Mathieu
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Copying cmake generated files to another machine


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' idea? Or will I bump  
into other gotcha's?


Any advice is appreciated...you have a lot more experience with this  
than I do!


snaroff

On Dec 7, 2009, at 1:10 AM, Óscar Fuentes wrote:


Hello Steve and Eric.

Eric Noulard 
writes:


2009/12/6 steve naroff :


May be we can think of "packaging" CMake itself along with the  
build tree?


Packaging the binaries isn't considered acceptable (we need a  
"pure" source

distribution with no binary files).


Sorry for being picky but you don't "require a pure source".

You want to have the file used by your target
build system (Makefile or any other "project file") to be shipped  
with

your source tree.


In the past, LLVM/clang had a manually crafted Visual Studio project
file. That worked fine for the purposes of the OP. It was "pure  
source"

because you obtained it directly from the svn repository along the
project source code and it was ready to build with VS, no intermediate
steps required. The VS project file was removed and this is causing
problems to the OP, because the "pure source" requirement is imposed
upon him by somebody else.

[snip]


A spin on your idea is to package the CMake source itself (and build
it from scratch, prior to building llvm/clang). Unfortunately, this
approach is quite "heavy" (but may be the cleanest given the
constraints).


For "the others" this would require:

1. build cmake.
2. invoke cmake for configuring LLVM/clang.
3. invoke VS for building the LLVM/clang.

You can solve 1&2 with a .bat file. With cmake 2.8, you can build LLVM
from the .bat file too (with the new "cmake --build" feature, IIRC),  
but

I guess that "them" are having too much fun building LLVM with the VS
IDE :-)


I see. Personnally I have another point of view regarding this.  Once
I decided to go for a CMake build system for my project, I consider
CMake to be part of the compiler suite.

If I require a compiler to be installed for compiling the source of  
my

project I do require CMake to be installed too.


That is very sensible but, unfortunately, the OP can't do much about  
it.


[snip]

--
Óscar

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] 32 bits compilation on x64 platform - how to find system libraries