Re: [CMake] Ada support

[Alan W. Irwin]

On 2007-11-13 21:52+0100 Alexander Camek wrote:


Hi,


[asked by Alexander Camek]
is there still the plan to use Ada with CMake?

[answered by Alexander Neundorf]
More or less, yes. Alan, what the current state ?


The PLplot Ada bindings are implemented as an Ada library. We use CMake to
build that library and also build our 14 Ada example executables using the
Ada-related CMake compiler files in the cmake/modules directory that is
referred to below. The required linking of Ada examples to our Ada library
and Ada library to our C library goes smoothly with CMake on Linux, Mac OS
X, _and_ MinGW.  (The last two platforms are second-hand reports, but from
reliable PLplot developers.) We have had no Cygwin or "raw" windows (windows
without MinGW or Cygwin) testing.

AC (or anybody else interested in building Ada executables and libraries
with CMake), if you have access to a gnat compiler (GNU gnat preferred since
that is what we have tested so far), just follow what we do in our svn trunk
(http://plplot.svn.sourceforge.net/viewvc/plplot/trunk/), and you should be
okay for linking Ada executables to Ada libraries.  Look for Ada-related
items in the following directories: cmake/modules (CMake Ada language files
and overall Ada setup), bindings/ada (for building the Ada library),
examples/ada (for building the examples), and test (to execute the built Ada
examples [and many others] as ctest tests).

So AN, that is the status report.  Furthermore, to answer the question
behind your question, I have not checked any of our Ada language support
files into CMake CVS because I have been distracted by several other higher
priorities.  I do plan to get to it eventually, but meanwhile, everybody is
welcome to use the PLplot svn to access the Ada language support files
for CMake.


[Alexander Camek continued]
Because when it is the plan to use it with CMake, then there will be a 
problem for using dlls under Windows.


That is not correct in the MinGW case.  All we can say for the Cygwin and
raw windows cases is they are untested, but the good report for MinGW is
certainly a positive indication for those other windows platforms.

AC, to pursue the Ada on windows question further, I suggest you first put
together a simple example following what we do above and confirm it works
for MinGW. (I will be happy to run the simple test on my Linux platform as
well.) Once you have confidence from such a simple test for MinGW (and
Linux), then it would be valuable to run the simple test on the other
windows platforms to actually see how the current CMake Ada language support
works in those cases.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__

Linux-powered Science
__
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] About supporting Debug_Static, Debug_Shared, Release_Static, Release_Shared build type

[Judy]

 Hi,

I'm trying write CMake files to generate VC++ project files which
could support Debug_Static, Debug_Shared, Release_Static,
Release_Shared for building libraries.
I have two configuration type "DEBUG" and "RELEASE", and two build
targets for static and dynamic build.

What I have below could only set compile flag "/MTd" and "/MDd" for
both debug and release build, how could I  set "/MT" and "/MD" for
release build?

ADD_LIBRARY (MYLIB STATIC src.cpp header.h }
SET_TARGET_PROPERTIES( MYLIB  PROPERTIES COMPILE_FLAGS "/MTd")

ADD_LIBRARY (MYLIB_Shared SHARED src.cpp header.h }
SET_TARGET_PROPERTIES( MYLIB_Shared  PROPERTIES COMPILE_FLAGS "/MDd")

Thanks a lot,

Judy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Re: dangerous regex in CHECK_C_SOURCE_COMPILES

[Brandon Van Every]

On Nov 13, 2007 6:28 PM, Bill Hoffman <[EMAIL PROTECTED]> wrote:
>
> Brandon Van Every wrote:
> > On Nov 13, 2007 3:35 PM, Bill Hoffman <[EMAIL PROTECTED]> wrote:
> >> A variable name should not contain special characters anyway.
> >
> > That, however, is not error checking or safety.  That's hope.  I
> > haven't synthesized an example that will kill CMake in the real world.
> >  At some point I will do so and enter it in the bug tracker, with
> > whatever level of severity it is worth.
> >
> >
>
> OK, so if you call the macro with incorrect arguments you will get the
> wrong answer, and some error about a bad regular expression.  However, I
> think that even if we did not use the MATCH thing for DEFINED, you would
> still get some really odd error, if you pass a variable name into a
> macro, that is not a valid variable name.  Again, can you come up with
> an example of this?  I just want to try the example against the "fix",
> and my guess is the results will not be much better than what we have now.

I don't have time for this at present but I will attempt to synthesize
a worst case in the future.


Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Re: dangerous regex in CHECK_C_SOURCE_COMPILES

[Bill Hoffman]

Brandon Van Every wrote:

On Nov 13, 2007 3:35 PM, Bill Hoffman <[EMAIL PROTECTED]> wrote:

A variable name should not contain special characters anyway.


That, however, is not error checking or safety.  That's hope.  I
haven't synthesized an example that will kill CMake in the real world.
 At some point I will do so and enter it in the bug tracker, with
whatever level of severity it is worth.




OK, so if you call the macro with incorrect arguments you will get the 
wrong answer, and some error about a bad regular expression.  However, I 
think that even if we did not use the MATCH thing for DEFINED, you would 
still get some really odd error, if you pass a variable name into a 
macro, that is not a valid variable name.  Again, can you come up with 
an example of this?  I just want to try the example against the "fix", 
and my guess is the results will not be much better than what we have now.


-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Performing cross-platform build - how ?

[Matthew McCormick]

On 11/13/07, Stephen Collyer <[EMAIL PROTECTED]> wrote:

1. Let's assume I want to do a Linux and Win32 build from the
same source tree.

2. I have a directory tree like:

./src/
./build/linux
./build/win32
./install/linux/
./install/win32/

All of my cross-platform source resides uder src. This whole
tree, both src and build is mounted so as to be visible to
my Linux box and Windows machine.

3. I set up CMakeList.txt files appropriately in . and the
various subdirs of src

4. On my Linux box, I cd into build/linux and I type:

cmake ../..


You don't want/need a CMakeLists.txt in '.'  You only need one in ./src/ and
sub directories. then

cd build/linux
ccmake ../../src
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Performing cross-platform build - how ?

[Alexander Neundorf]

On Tuesday 13 November 2007, Stephen Collyer wrote:
> I am almost a total cmake newbie. I've been looking through
> the wiki for information on how one actually performs a cross-platform
> build with cmake, but I can't find any. Can someone tell me if my
> thinking outline here makes sense:
>
> 1. Let's assume I want to do a Linux and Win32 build from the
> same source tree.
>
> 2. I have a directory tree like:
>
> ./src/
> ./build/linux
> ./build/win32
> ./install/linux/
> ./install/win32/
>
> All of my cross-platform source resides uder src. This whole
> tree, both src and build is mounted so as to be visible to
> my Linux box and Windows machine.
>
> 3. I set up CMakeList.txt files appropriately in . and the
> various subdirs of src
>
> 4. On my Linux box, I cd into build/linux and I type:
>
> cmake ../..
>
> which creates all of the cmake files and directories suitable
> for a Linux build under build/linux. I type
>
> make all
>
> >from the same directory, and everything is built for my Linux
>
> environment under build/linux
>
> 5. On my Windows box, I cd into build/src, and I type the
> same(ish) commands, to have a build made under build/win32.

Yes. But that depends what you want to use for building: MSVC, cl+nmake, 
mingw, ... 

> 6. (Now things get very fuzzy ..) I run some command
> (make install, I guess) which moves my deliverable binaries
> into the install/linux and install/win32 trees, based
> upon some CMakeList.txt configuration I did earlier to
> pick out the stuff I want to deliver

Yes, it's the install target.

> 7. (Things get even fuzzier ..) I run some commands to
> package stuff up from the install trees into .tgz, .rpm
> etc using CPack. I have no idea at the moment how this works.

Build the "packages" target, that should do it.

Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Performing cross-platform build - how ?

[Stephen Collyer]

I am almost a total cmake newbie. I've been looking through
the wiki for information on how one actually performs a cross-platform
build with cmake, but I can't find any. Can someone tell me if my
thinking outline here makes sense:

1. Let's assume I want to do a Linux and Win32 build from the
same source tree.

2. I have a directory tree like:

./src/
./build/linux
./build/win32
./install/linux/
./install/win32/

All of my cross-platform source resides uder src. This whole
tree, both src and build is mounted so as to be visible to
my Linux box and Windows machine.

3. I set up CMakeList.txt files appropriately in . and the
various subdirs of src

4. On my Linux box, I cd into build/linux and I type:

cmake ../..

which creates all of the cmake files and directories suitable
for a Linux build under build/linux. I type

make all

from the same directory, and everything is built for my Linux
environment under build/linux

5. On my Windows box, I cd into build/src, and I type the
same(ish) commands, to have a build made under build/win32.

6. (Now things get very fuzzy ..) I run some command
(make install, I guess) which moves my deliverable binaries
into the install/linux and install/win32 trees, based
upon some CMakeList.txt configuration I did earlier to
pick out the stuff I want to deliver

7. (Things get even fuzzier ..) I run some commands to
package stuff up from the install trees into .tgz, .rpm
etc using CPack. I have no idea at the moment how this works.

Am I thinking along the right lines ? Anyone care to
point me to the details in the wiki, or wherever, or
to fill them in here ?

-- 
Regards

Steve Collyer
Netspinner Ltd
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Re: dangerous regex in CHECK_C_SOURCE_COMPILES

[Brandon Van Every]

On Nov 13, 2007 3:35 PM, Bill Hoffman <[EMAIL PROTECTED]> wrote:
>
> A variable name should not contain special characters anyway.

That, however, is not error checking or safety.  That's hope.  I
haven't synthesized an example that will kill CMake in the real world.
 At some point I will do so and enter it in the bug tracker, with
whatever level of severity it is worth.


Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: Fwd: [CMake] Generating static and shared libs

[Christian Ehrlicher]

Alexander Camek schrieb:
> Hi,
> 
>> No, you *really* should read on www.mingw.org and inform you about
>> import libs.
> 
> I will do that, thanks.
> thought that i had understand them :(
> 
I already told you all you have to know
Windows needs 'static import libs' to link against a shared lib. Nothing
more :)


Christian
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: Fwd: [CMake] Generating static and shared libs

[Alexander Camek]

Hi,


No, you *really* should read on www.mingw.org and inform you about
import libs.


I will do that, thanks.
thought that i had understand them :(

Greetings

Alexander
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: Fwd: [CMake] Generating static and shared libs

[Christian Ehrlicher]

Alexander Camek schrieb:
> Hi,
> 
>>> I am using here MinGW C and C++ source code to build some libraries.
>>>
>>> Now what me wonders is that I am getting sometimes static libraries
>>> additional to my dynamic libraries.
>>
>> I think you are talking about the "import library"
>>
>> http://www.mingw.org/MinGWiki/index.php/sample%20DLL
> 
> Nope, I don't talk about that.
> 
> I am talking about the problem, that when I use ADD_LIBRARY(libname
> SHARED ${SOURCE}) and I let all my files create in a common directory
> setted with LIBRARY_OUTPUT_PATH, then sometimes both are created.
> 
> So as an example I find there both kind of files.
> I have got there a libname.dll and a libname.dll.a.
> 
> If this is a desired result, then why both the .dll and .dll.a are not
> generated.
> 
.dll.a is not a static lib in the way you know it. It's a static import
lib. See below.
> 
>> I don't know MinGW well but I think its different from static libs.
>>
>>> Although I always build shared libraries.
>>>
>>> What is the strategy when to build only the dynamic libraries and when
>>> to build both?
>>
>> I think you'll find answers in MinGW docs and not in CMake
> 
> I think this is a CMake problem ;).
> 
No, you *really* should read on www.mingw.org and inform you about
import libs.


Christian
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Ada support

[Alexander Camek]

Hi,



is there still the plan to use Ada with CMake?


More or less, yes. 
Alan, what the current state ?


Because when it is the plan to use it with CMake, then there will be a 
problem for using dlls under Windows.


Without using the gnatbind call by libraries it is not possible to call 
a function by using LoadLibrary and call that function.


And if you want to use gnatbind you need a first compile step in order 
to create the .ali files. These are needed to create the binding file 
(mostly starting with b~ in the name).


After that you need to compile this one, too, and then link all files 
together.


Greetings

Alexander
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: Fwd: [CMake] Generating static and shared libs

[Alexander Camek]

Hi,


I am using here MinGW C and C++ source code to build some libraries.

Now what me wonders is that I am getting sometimes static libraries
additional to my dynamic libraries.


I think you are talking about the "import library"

http://www.mingw.org/MinGWiki/index.php/sample%20DLL


Nope, I don't talk about that.

I am talking about the problem, that when I use ADD_LIBRARY(libname 
SHARED ${SOURCE}) and I let all my files create in a common directory 
setted with LIBRARY_OUTPUT_PATH, then sometimes both are created.


So as an example I find there both kind of files.
I have got there a libname.dll and a libname.dll.a.

If this is a desired result, then why both the .dll and .dll.a are not 
generated.




I don't know MinGW well but I think its different from static libs.


Although I always build shared libraries.

What is the strategy when to build only the dynamic libraries and when
to build both?


I think you'll find answers in MinGW docs and not in CMake


I think this is a CMake problem ;).

Alexander
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake -DCMAKE_CXX_COMPILER=g++ does not work as expected

[Alexander Neundorf]

On Tuesday 13 November 2007, Erik Johansson wrote:
> Hi,
>
> Running cmake with -DCMAKE_CXX_COMPILER=g++ gives the following output:
> -- Check for working CXX compiler: g++
> -- Check for working CXX compiler: g++ -- works
>
> But building fails since it tries to use g++ from the build dir. From
> CMakeCache.txt:
> CMAKE_CXX_COMPILER:FILEPATH=/home/erik/tmp/test/build/g++
>
> Running cmake with -DCMAKE_CXX_COMPILER:FILEPATH=g++ or even
> -DCMAKE_CXX_COMPILER:STRING=g++ gives the expected result. From
> CMakeCache.txt:
> CMAKE_CXX_COMPILER:FILEPATH=/usr/lib/ccache/g++
>
> Is this the expected behavior?

Hmm, yes, with cmake 2.4 if you don't specify the type it doesn't go into the 
cache.
Don't do that, but set the environment variable CXX instead.

It should work with cmake cvs.

Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Re: dangerous regex in CHECK_C_SOURCE_COMPILES

[Bill Hoffman]

Brandon Van Every wrote:

I see the same construct in CHECK_INCLUDE_FILES.  What is the intent?
This is not safe.

Cheers,
Brandon Van Every


On Nov 7, 2007 11:38 AM, Brandon Van Every <[EMAIL PROTECTED]> wrote:

It begins with:

MACRO(CHECK_C_SOURCE_COMPILES SOURCE VAR)
  IF("${VAR}" MATCHES "^${VAR}$")

What is the intent here?  If ${VAR} contains regex special characters
you're going to get all kinds of weird and nasty behavior.



It is checking to see if the variable has been set, from before DEFINED 
was added to if.  However, I don't see the problem.  This is the 
argument to a macro that is supposed to be a valid variable name.  A 
variable name should not contain special characters anyway.


-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Fwd: [CMake] Generating static and shared libs

[Eric Noulard]

I did forgot the list

-- Forwarded message --
From: Eric Noulard <[EMAIL PROTECTED]>
Date: 13 nov. 2007 21:34
Subject: Re: [CMake] Generating static and shared libs
To: Alexander Camek <[EMAIL PROTECTED]>


2007/11/13, Alexander Camek <[EMAIL PROTECTED]>:
> Hi all,
>
> I am using here MinGW C and C++ source code to build some libraries.
>
> Now what me wonders is that I am getting sometimes static libraries
> additional to my dynamic libraries.

I think you are talking about the "import library"

http://www.mingw.org/MinGWiki/index.php/sample%20DLL

I don't know MinGW well but I think its different from static libs.

> Although I always build shared libraries.
>
> What is the strategy when to build only the dynamic libraries and when
> to build both?

I think you'll find answers in MinGW docs and not in CMake
--
Erk


-- 
Erk
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Re: dangerous regex in CHECK_C_SOURCE_COMPILES

[David Cole]

The intent is to use a construct that works even with older CMake versions
such that the code enclosed in the construct only gets run on the first
configure.

I'm pretty sure it's only dangerous with variables that have dangerous names
in the first place.

Do you have a concrete example that is giving you problems?

On 11/13/07, Brandon Van Every <[EMAIL PROTECTED]> wrote:
>
> I see the same construct in CHECK_INCLUDE_FILES.  What is the intent?
> This is not safe.
>
> Cheers,
> Brandon Van Every
>
>
> On Nov 7, 2007 11:38 AM, Brandon Van Every <[EMAIL PROTECTED]> wrote:
> > It begins with:
> >
> > MACRO(CHECK_C_SOURCE_COMPILES SOURCE VAR)
> >   IF("${VAR}" MATCHES "^${VAR}$")
> >
> > What is the intent here?  If ${VAR} contains regex special characters
> > you're going to get all kinds of weird and nasty behavior.
> >
> >
> > Cheers,
> > Brandon Van Every
> >
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] cmake -DCMAKE_CXX_COMPILER=g++ does not work as expected

[Erik Johansson]

Hi,

Running cmake with -DCMAKE_CXX_COMPILER=g++ gives the following output:
-- Check for working CXX compiler: g++
-- Check for working CXX compiler: g++ -- works

But building fails since it tries to use g++ from the build dir. From
CMakeCache.txt:
CMAKE_CXX_COMPILER:FILEPATH=/home/erik/tmp/test/build/g++

Running cmake with -DCMAKE_CXX_COMPILER:FILEPATH=g++ or even
-DCMAKE_CXX_COMPILER:STRING=g++ gives the expected result. From
CMakeCache.txt:
CMAKE_CXX_COMPILER:FILEPATH=/usr/lib/ccache/g++

Is this the expected behavior?

// Erik

P.S. Using cmake 2.4.7

-- 
Erik Johansson
Home Page: http://ejohansson.se/
PGP Key: http://ejohansson.se/erik.asc
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Ada support

[Alexander Neundorf]

On Tuesday 13 November 2007, Alexander Camek wrote:
> Hi all,
>
> is there still the plan to use Ada with CMake?

More or less, yes. 
Alan, what the current state ?

Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Generating static and shared libs

[Alexander Camek]

Hi all,

I am using here MinGW C and C++ source code to build some libraries.

Now what me wonders is that I am getting sometimes static libraries 
additional to my dynamic libraries.

Although I always build shared libraries.

What is the strategy when to build only the dynamic libraries and when 
to build both?


Thanks for your help.

Greetings

Alexander
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Ada support

[Alexander Camek]

Hi all,

is there still the plan to use Ada with CMake?

Greetings

Alexander
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Re: dangerous regex in CHECK_C_SOURCE_COMPILES

[Brandon Van Every]

I see the same construct in CHECK_INCLUDE_FILES.  What is the intent?
This is not safe.

Cheers,
Brandon Van Every


On Nov 7, 2007 11:38 AM, Brandon Van Every <[EMAIL PROTECTED]> wrote:
> It begins with:
>
> MACRO(CHECK_C_SOURCE_COMPILES SOURCE VAR)
>   IF("${VAR}" MATCHES "^${VAR}$")
>
> What is the intent here?  If ${VAR} contains regex special characters
> you're going to get all kinds of weird and nasty behavior.
>
>
> Cheers,
> Brandon Van Every
>
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Linking Libraries

[Brandon Van Every]

On Nov 12, 2007 12:32 PM,  <[EMAIL PROTECTED]> wrote:
>
> SUBDIRS( wrap )

This is archaic.  The preferred command nowadays is ADD_SUBDIRECTORY.
There are some differences between the two commands IIRC.  I don't
know that it affects your problem, but who knows?

Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] RVDS and CMake

[Bill Hoffman]

Alexander Neundorf wrote:

On Tuesday 13 November 2007, Luis Ramirez wrote:

I'm running with cmake release 2.4.7 according with:

http://www.kwwidgets.org/Wiki/CMake_Cross_Compiling

Basically it said that cross compilers are supported from 2.6.0 (not yet
released).

The compilation with cross compilers is not supported in my current
version. I suppose that this could be the main problem, isn't it?

Should I work with a development version 2.5.something for the moment or
make me my current compilation from the CVS?


Yes, using cmake cvs (which is 2.5.something) should work better.
But you still may have the problem with the path.
You can use e.g. mingw make or you can also use the GNU make included here:
http://unxutils.sourceforge.net/
They both use windows paths.



The key is you don't want to build cmake against the cygwin runtime. 
You could use the nightly windows snapshot:


http://www.cmake.org/HTML/Download.html#cvs


-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] RVDS and CMake

[Alexander Neundorf]

On Tuesday 13 November 2007, Luis Ramirez wrote:
> I'm running with cmake release 2.4.7 according with:
>
> http://www.kwwidgets.org/Wiki/CMake_Cross_Compiling
>
> Basically it said that cross compilers are supported from 2.6.0 (not yet
> released).
>
> The compilation with cross compilers is not supported in my current
> version. I suppose that this could be the main problem, isn't it?
>
> Should I work with a development version 2.5.something for the moment or
> make me my current compilation from the CVS?

Yes, using cmake cvs (which is 2.5.something) should work better.
But you still may have the problem with the path.
You can use e.g. mingw make or you can also use the GNU make included here:
http://unxutils.sourceforge.net/
They both use windows paths.

Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] RVDS and CMake

[Luis Ramirez]

I'm running with cmake release 2.4.7 according with:

http://www.kwwidgets.org/Wiki/CMake_Cross_Compiling

Basically it said that cross compilers are supported from 2.6.0 (not yet
released).

The compilation with cross compilers is not supported in my current version.
I suppose that this could be the main problem, isn't it?

Should I work with a development version 2.5.something for the moment or
make me my current compilation from the CVS?

I have test CMake for win32 with "Unix Makefile" and appears the same error.

On Nov 13, 2007 5:36 PM, Bill Hoffman <[EMAIL PROTECTED]> wrote:

> Luis Ramirez wrote:
> > Hi people,
> >
> > I would like to know if someone has experience with armcc compiler
> > provide by the RVDS compilation suite. I am work normally with cygwin
> > environment and my current project has manual Makefile that are
> > impossible to manage for new people. I would like to suggest a
> > construction software as CMake but I couldn't configure a simple project
> > with the armcc compiler. The ARM compiler is not the Dashboard with the
> > testing building system but I don't undertand why it will not work.
> >
> > I have posted the output at the end of the mail. I think that the error
> > is in the generation of the example files "build.make" and the
> > "testCCompiler.c". If I use gcc it works properly.
> >
> > If someone has an idea please comment to me.
> >
> > -
> > $cmake.exe --debug-output
> > Running with debug output on.
> > -- Check for working C compiler: /home/lramirez/bin/armcc.exe
> > -- Check for working C compiler: /home/lramirez/bin/armcc.exe -- broken
> > CMake Error: Error in cmake code at
> > /usr/share/cmake-2.4.7/Modules/CMakeTestCCompiler.cmake:33:
> > MESSAGE The C compiler "/home/lramirez/bin/armcc.exe" is not able to
> > compile a simple test program.
> > It fails with the following output:
> >  make -f CMakeFiles/cmTryCompileExec.dir/build.make
> > CMakeFiles/cmTryCompileExec.dir/build
> > make[1]: Entering directory `/tmp/CMakeExample/CMakeFiles/CMakeTmp'
> > /usr/bin/cmake.exe -E cmake_progress_report
> > /tmp/CMakeExample/CMakeFiles/CMakeTmp/CMakeFiles 1
> > Building C object CMakeFiles/cmTryCompileExec.dir/testCCompiler.o
> > /home/lramirez/bin/armcc.exe   -o
> > CMakeFiles/cmTryCompileExec.dir/testCCompiler.o   -c
> > /tmp/CMakeExample/CMakeFiles/CMakeTmp/testCCompiler.c
> > "no source": Error:  #5: cannot open source input file
> > "\tmp\CMakeExample\CMakeFiles\CMakeTmp\testCCompiler.c": No such file or
> > directory
> > make[1]: *** [CMakeFiles/cmTryCompileExec.dir/testCCompiler.o] Error 1
> > make[1]: Leaving directory `/tmp/CMakeExample/CMakeFiles/CMakeTmp'
> > make: *** [cmTryCompileExec/fast] Error 2
> >
> >
> Looks like the compiler does not understand cygwin paths.  I would
> recommend using the windows build of CMake, with the "Unix Makefiles"
> generator.  Then set CXX and CC before running cmake, and it should work.
>
> -Bill
>



-- 
Luis Ramírez González.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] RVDS and CMake

[Bill Hoffman]

Luis Ramirez wrote:

Hi people,

I would like to know if someone has experience with armcc compiler 
provide by the RVDS compilation suite. I am work normally with cygwin 
environment and my current project has manual Makefile that are 
impossible to manage for new people. I would like to suggest a 
construction software as CMake but I couldn't configure a simple project 
with the armcc compiler. The ARM compiler is not the Dashboard with the 
testing building system but I don't undertand why it will not work.


I have posted the output at the end of the mail. I think that the error 
is in the generation of the example files "build.make" and the 
"testCCompiler.c". If I use gcc it works properly.


If someone has an idea please comment to me.

-
$cmake.exe --debug-output
Running with debug output on.
-- Check for working C compiler: /home/lramirez/bin/armcc.exe
-- Check for working C compiler: /home/lramirez/bin/armcc.exe -- broken
CMake Error: Error in cmake code at
/usr/share/cmake-2.4.7/Modules/CMakeTestCCompiler.cmake:33:
MESSAGE The C compiler "/home/lramirez/bin/armcc.exe" is not able to 
compile a simple test program.

It fails with the following output:
 make -f CMakeFiles/cmTryCompileExec.dir/build.make 
CMakeFiles/cmTryCompileExec.dir/build

make[1]: Entering directory `/tmp/CMakeExample/CMakeFiles/CMakeTmp'
/usr/bin/cmake.exe -E cmake_progress_report 
/tmp/CMakeExample/CMakeFiles/CMakeTmp/CMakeFiles 1

Building C object CMakeFiles/cmTryCompileExec.dir/testCCompiler.o
/home/lramirez/bin/armcc.exe   -o 
CMakeFiles/cmTryCompileExec.dir/testCCompiler.o   -c 
/tmp/CMakeExample/CMakeFiles/CMakeTmp/testCCompiler.c
"no source": Error:  #5: cannot open source input file 
"\tmp\CMakeExample\CMakeFiles\CMakeTmp\testCCompiler.c": No such file or 
directory

make[1]: *** [CMakeFiles/cmTryCompileExec.dir/testCCompiler.o] Error 1
make[1]: Leaving directory `/tmp/CMakeExample/CMakeFiles/CMakeTmp'
make: *** [cmTryCompileExec/fast] Error 2


Looks like the compiler does not understand cygwin paths.  I would 
recommend using the windows build of CMake, with the "Unix Makefiles" 
generator.  Then set CXX and CC before running cmake, and it should work.


-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] RVDS and CMake

[Luis Ramirez]

Hi people,

I would like to know if someone has experience with armcc compiler provide
by the RVDS compilation suite. I am work normally with cygwin environment
and my current project has manual Makefile that are impossible to manage for
new people. I would like to suggest a construction software as CMake but I
couldn't configure a simple project with the armcc compiler. The ARM
compiler is not the Dashboard with the testing building system but I don't
undertand why it will not work.

I have posted the output at the end of the mail. I think that the error is
in the generation of the example files "build.make" and the "testCCompiler.c".
If I use gcc it works properly.

If someone has an idea please comment to me.

-
$cmake.exe --debug-output
Running with debug output on.
-- Check for working C compiler: /home/lramirez/bin/armcc.exe
-- Check for working C compiler: /home/lramirez/bin/armcc.exe -- broken
CMake Error: Error in cmake code at
/usr/share/cmake-2.4.7/Modules/CMakeTestCCompiler.cmake:33:
MESSAGE The C compiler "/home/lramirez/bin/armcc.exe" is not able to compile
a simple test program.
It fails with the following output:
 make -f CMakeFiles/cmTryCompileExec.dir/build.make
CMakeFiles/cmTryCompileExec.dir/build
make[1]: Entering directory `/tmp/CMakeExample/CMakeFiles/CMakeTmp'
/usr/bin/cmake.exe -E cmake_progress_report
/tmp/CMakeExample/CMakeFiles/CMakeTmp/CMakeFiles 1
Building C object CMakeFiles/cmTryCompileExec.dir/testCCompiler.o
/home/lramirez/bin/armcc.exe   -o
CMakeFiles/cmTryCompileExec.dir/testCCompiler.o   -c
/tmp/CMakeExample/CMakeFiles/CMakeTmp/testCCompiler.c
"no source": Error:  #5: cannot open source input file
"\tmp\CMakeExample\CMakeFiles\CMakeTmp\testCCompiler.c": No such file or
directory
make[1]: *** [CMakeFiles/cmTryCompileExec.dir/testCCompiler.o] Error 1
make[1]: Leaving directory `/tmp/CMakeExample/CMakeFiles/CMakeTmp'
make: *** [cmTryCompileExec/fast] Error 2


CMake will not be able to correctly generate this project.
Current CMake stack:
[2] /usr/share/cmake-2.4.7/Modules/CMakeTestCCompiler.cmake
[1] /tmp/CMakeExample/CMakeLists.txt
-- Configuring done
---
-- 
Luis Ramírez González.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Linking Libraries

[abboti]

I'll also add that the project compiles using MS Visual C++ with the
LINK_LIBRARIES removed (no reference to these VTKLibraries anywhere in
the top-level CMakeLists.  
 


==Original message text===
On Tue, 13 Nov 2007 7:17:50 EST [EMAIL PROTECTED] wrote:

Adding each of the libraries to the TARGET_LINK_LIBRARIES, instead of
this LINK_LIBRARIES did not work.  This is the part that confuses me the
most.  
What LINK_LIBRARIES doing that TARGET_LINK_LIBRARIES is not?



==Original message text===
On Mon, 12 Nov 2007 12:45:13 EST "Brandon Van Every" wrote:

On Nov 12, 2007 12:32 PM,  <[EMAIL PROTECTED]> wrote:
>
> I've created a project (Farsight) that has this top-level CMakeLists file
> (segment shown).  The subdirs also have theirs.  The cpp files in /seg
> use VTK libraries.  I have found that the project compiles using MS
> Visual Studio, but not using g++.
>
> To get g++ to work I added this to the CMakeLists shown below:
> LINK_LIBRARIES(
>   VTKCommon
>   VTKIO
>   VTKFiltering
> )
>
> I understand this to be an old command that is no longer necessary, and I
> don't want to have it in this CMakeLists file because I don't need to
> know what each module (subdir) requires for libraries.

So why don't you just add VTKCommon VTKIO VTKFiltering to the
appropriate TARGET_LINK_LIBRARIES commands?


Cheers,
Brandon Van Every


>
>
##
##
> # Snippet of Top-Level CMakeLists.txt
>
##
##
>
> SUBDIRS( wrap )
>
>
> # here we instruct CMake to build "Farsight" executable from all
> # source files and place it in the "bin" folder
>
> ADD_EXECUTABLE( Farsight
> ${FARSIGHT_SRCS}
> )
>
> # last thing we have to do is to tell CMake what libraries our executable
> needs,
> # luckily FIND_PACKAGE prepared QT_LIBRARIES variable for us:
> TARGET_LINK_LIBRARIES( Farsight
> )
>
>
>
> #
> The CMakeLists.txt in \wrap
> #
> SET( MY_WRAPPERS_SRCS
> itkimage2qimage.cpp
> qimage2itkimage.cpp
> vtkLSMReader.cxx
> )
>
> SET( MY_WRAPPERS_HDRS
> qimage2itkimage.h
> vtkLSMReader.h
> vtkBXDProcessingWin32Header.h
> )
>
> ADD_LIBRARY( fswrappers
>  ${MY_WRAPPERS_SRCS}
>  ${MY_WRAPPERS_HDRS}
> )
>
> TARGET_LINK_LIBRARIES( fswrappers ${QT_LIBRARIES} VTKCommon VTKFiltering )
>
>
>
>
>
>
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake>___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake===End of original message 
text===



___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
===End of original message text===



___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] How to redirect output (.o file generattion) in specific directory

[Bill Hoffman]

Amit C. Kr. Saluja wrote:

No, AFAIK this is fix and you can't change it.

Why do you want to do that ?
(I recommend you just get used to the location of
the object files).



I want to add the gcc options for gcov in Makefile.
The gcc flags dumps the *.gcno files at the location
of .o files.

So, if you run the gcov on .c files, then these files
should be in the current directory where from you are
running gcov. With existing CMake Framework for .o
files, either one should copy *.gcno files in current
directory or should run gcov from .O files directory.

If any othjer option is available? Do help me out!!



I am not sure this helps but ctest supports gcov and gccc.  It just 
collects all the gcov output files and merges them.  It has no problems 
with the current output and location of .o files in cmake.


-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Linking Libraries

[abboti]

Adding each of the libraries to the TARGET_LINK_LIBRARIES, instead of
this LINK_LIBRARIES did not work.  This is the part that confuses me the
most.  
What LINK_LIBRARIES doing that TARGET_LINK_LIBRARIES is not?



==Original message text===
On Mon, 12 Nov 2007 12:45:13 EST "Brandon Van Every" wrote:

On Nov 12, 2007 12:32 PM,  <[EMAIL PROTECTED]> wrote:
>
> I've created a project (Farsight) that has this top-level CMakeLists file
> (segment shown).  The subdirs also have theirs.  The cpp files in /seg
> use VTK libraries.  I have found that the project compiles using MS
> Visual Studio, but not using g++.
>
> To get g++ to work I added this to the CMakeLists shown below:
> LINK_LIBRARIES(
>   VTKCommon
>   VTKIO
>   VTKFiltering
> )
>
> I understand this to be an old command that is no longer necessary, and I
> don't want to have it in this CMakeLists file because I don't need to
> know what each module (subdir) requires for libraries.

So why don't you just add VTKCommon VTKIO VTKFiltering to the
appropriate TARGET_LINK_LIBRARIES commands?


Cheers,
Brandon Van Every


>
>
##
##
> # Snippet of Top-Level CMakeLists.txt
>
##
##
>
> SUBDIRS( wrap )
>
>
> # here we instruct CMake to build "Farsight" executable from all
> # source files and place it in the "bin" folder
>
> ADD_EXECUTABLE( Farsight
> ${FARSIGHT_SRCS}
> )
>
> # last thing we have to do is to tell CMake what libraries our executable
> needs,
> # luckily FIND_PACKAGE prepared QT_LIBRARIES variable for us:
> TARGET_LINK_LIBRARIES( Farsight
> )
>
>
>
> #
> The CMakeLists.txt in \wrap
> #
> SET( MY_WRAPPERS_SRCS
> itkimage2qimage.cpp
> qimage2itkimage.cpp
> vtkLSMReader.cxx
> )
>
> SET( MY_WRAPPERS_HDRS
> qimage2itkimage.h
> vtkLSMReader.h
> vtkBXDProcessingWin32Header.h
> )
>
> ADD_LIBRARY( fswrappers
>  ${MY_WRAPPERS_SRCS}
>  ${MY_WRAPPERS_HDRS}
> )
>
> TARGET_LINK_LIBRARIES( fswrappers ${QT_LIBRARIES} VTKCommon VTKFiltering )
>
>
>
>
>
>
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake>
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
===End of original message text===



___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

RE: [CMake] Choosing between debug and release variants of third-party libraries

[Torsten Martinsen]

Philip Lowman  wrote:

> So you can't do something like this?
>
> FIND_LIBRARY(qtmain_release qtmain
>PATHS "C:/lang/qt/3.3.4r/lib" NO_DEFAULT_PATH)
> FIND_LIBRARY(qtmain_debug qtmain
>PATHS "C:/lang/qt/3.3.4/lib" NO_DEFAULT_PATH)
>
> # declare your targets.
>
> TARGET_LINK_LIBRARIES(foo release ${qtmain_release})
> TARGET_LINK_LIBRARIES(food debug ${qtmain_debug})
>
> If something like that doesn't work I would file a bug for sure.

No, I cannot, because CMake still tells me

It is impossible to order the linker search path in such a way that 
libraries specified as full paths will be picked by the linker.
Directories and libraries involved are:
Directory: c:/lang/Qt/3.3.4/lib contains:
Library: C:/lang/qt/3.3.4r/lib/qtmain.lib

Directory: c:/lang/qt/3.3.4/lib contains:
Library: C:/lang/qt/3.3.4r/lib/qtmain.lib

Directory: c:/lang/qt/3.3.4r/lib contains:
Library: C:/lang/qt/3.3.4/lib/qtmain.lib

-Torsten

This e-mail and any files sent with it contain information that may be 
privileged or confidential and is the property of the GateHouse Group. This 
information is intended solely for the person to whom it is addressed. If you 
are not the intended recipient, you are not authorized to read, print, retain, 
copy, disseminate, distribute, or use the message or any part thereof. If you 
have received this e-mail in error, please notify the sender immediately, and 
delete all copies of this message. In accordance with GateHouse Security 
Policy, e-mails sent or received may be monitored.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] How to redirect output (.o file generattion) in specific directory

[Amit C. Kr. Saluja]

> No, AFAIK this is fix and you can't change it.
> 
> Why do you want to do that ?
> (I recommend you just get used to the location of
> the object files).


I want to add the gcc options for gcov in Makefile.
The gcc flags dumps the *.gcno files at the location
of .o files.

So, if you run the gcov on .c files, then these files
should be in the current directory where from you are
running gcov. With existing CMake Framework for .o
files, either one should copy *.gcno files in current
directory or should run gcov from .O files directory.

If any othjer option is available? Do help me out!!

regards
Amit
--- Alexander Neundorf <[EMAIL PROTECTED]>
wrote:

> On Monday 12 November 2007, Amit C. Kr. Saluja
> wrote:
> > Eric,
> > Thanks for this info!
> >
> > > EXECUTABLE_OUTPUT_PATH
> > > LIBRARY_OUTPUT_PATH
> >
> > These are global CMake variables. If we change it
> then
> > the EXECUTABLE & LIBRARY path of all the exe and
> libs
> > changes but not for .os The.os are still generated
> in
> > CMakeFiles/ directory.
> >
> > Can CMAKE_CURRENT_BINARY_DIR could do something?
> 
> No, AFAIK this is fix and you can't change it.
> 
> Why do you want to do that ?
> (I recommend you just get used to the location of
> the object files).
> 
> Alex
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
> 




  

Be a better pen pal. 
Text or chat with friends inside Yahoo! Mail. See how.  
http://overview.mail.yahoo.com/
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: Re: [CMake] Add include files

[Yinon Ehrlich]

Alexander Neundorf wrote:

On Sunday 11 November 2007, Yinon Ehrlich wrote:
  

Hi,

* I'm new to CMake, trying to convert our existing GNU Makefiles to CMake.
* I have a GCC compilation line that uses GCC's "-include" direction



The argument to -include is a file which will be included, right ?

  

(Instead of having multiple identical "#include" lines within the source
code.)

  ==> Does anyone has an idea how can I implement this feature with CMake ?



You could do it using ADD_DEFINITIONS(-include ...)
but I would suggest you actually include that file everywhere (using -include 
*might* make the cmake dependency scanning miss some dependencies)


Alex

  

Thanks, Alex !

Two questions, and an idea:

1. Why it could harm the dependency checking - because when including a 
file this way it is not checked by the CMake dependency scanner ?
2. I found that MSVC 2003 & 2005 has similar option called "forced 
include" (its switch-syntax is /FI ). I also saw that it 
appears in CMake's sources:
Source/cmLocalVisualStudio7Generator.cxx:353: {"ForcedIncludeFiles", 
"FI", "Forced include files", "",


The real *pain* here is compatibility. I think the best solution will be 
to write a module that adds forced includes (either "-include" for GCC 
or "/FI" for MSVC) and maybe also check their dependencies. Please tell 
me what you think.


Thanks,
Yinon

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake