[CMake] add_definitions() or set_target_properties(... COMPILE_FLAGS)?

[Dizzy]

Hello

I recently noticed that I am using add_definitions() for general compiler 
flags (that have been checked previously with check_cxx_compiler_flag()) not 
just "-D" flags. I also know this works not only when compiling with gcc 
based compilers (including mingw on Windows) but also with cl.exe and Visual 
Studio. Should the add_definitions() documentation be more complete or I am 
doing something unportable?

There is also the alternative of using set_target_properties(... 
COMPILE_FLAGS) to set general compile flags but I need something to set for 
al targets inherited from some point and not repeat this command for every 
target.

Thanks!

-- 
Mihai RUSU  Email: [EMAIL PROTECTED]
"Linux is obsolete" -- AST
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Changing the default name "CMakeLists.txt"

[Sylvain Benner]

Martin Lütken a écrit :
Is it possible to change the default the default 
filename "CMakeLists.txt" cmake looks for to something different ?
 
If not, then does anyone have an idea how hard it would be to add a 
possiblity (command line option I guess) like that to the cmake source 
code ?



No there is no possibilities to change it.
If you really want to, just use the file you want and in your 
CMakeLists.txt do :

INCLUDE("your file")

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

Re: [CMake] Changing the default name "CMakeLists.txt"

[Dizzy]

On Tuesday 28 August 2007 12:05:49 Martin Lütken wrote:
> If not, then does anyone have an idea how hard it would be to add a
> possiblity (command line option I guess) like that to the cmake source code
> ?

From a simple grep in the cmake CVS sources I think that to add such an option 
first would require to have a unified place with the "CMakeLists.txt" string 
value because currently there are about 15 different places in code where the 
string is hardcoded, about 30 places where it appears in messages generated 
from the code and A LOT of code comments and cmake module comments where it's 
used (tho the comments can be left in place since they still make sense 
talking about a CMakeLists.txt file even if that is configurable).

All in all I don't think it's very hard to do it, would result in a better 
cmake code organization too (not having scattered "CMakeLists.txt" magic 
value all over the code).

-- 
Mihai RUSU  Email: [EMAIL PROTECTED]
"Linux is obsolete" -- AST
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Changing the default name "CMakeLists.txt"

[Martin Lütken]

Is it possible to change the default the default filename "CMakeLists.txt" 
cmake looks for to something different ?
 
If not, then does anyone have an idea how hard it would be to add a possiblity 
(command line option I guess) like that to the cmake source code ?
 
 

Martin Lütken
Developer

 NetOp® Danware Data 
A/S * Bregnerodvej 127 * DK-3460 Birkerod * Denmark
Tel. +45 4590 2525 * Direct +45 4590 2532
www.netop.com    

Disclaimer - This message is for the designated recipient only and may contain 
confidential or privileged information. If you have received this message by 
mistake, please notify the sender by replying to the e-mail and delete the 
message without copying or disclosing.

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

[CMake] Programs linked to .a or .so libraries?

[Convey Christian J NPRI]

> -Original Message-
> From: Philip Lowman [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 28, 2007 12:15 AM
> To: Convey Christian J NPRI
> Cc: cmake@cmake.org
> Subject: Re: [CMake] Programs linked to .a or .so libraries?
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Convey Christian J NPRI wrote:
> > On Linux, I'm building a program that is linked against the
> "ncurses"
> > library. 
> > 
> > In CMake, what decides whether my program will be linked to 
> > libcurses.a or to libcurses.so ?
> > 
> > I'd like to minimize external dependencies in the build 
program, so 
> > whenever possible I'd like to link to the .a version.  But
> if nothing
> > else I need to know which version (static vs. dynamic) of a given 
> > library my program is linked to.
> 
> This is another one of those things that has not been 
implemented in 
> CMake but which has been brought up before.
> Implementing this on UNIX would be easy but I'm not sure on
> Win32 since you couldn't simply rely on file extension to 
determine if 
> it's a static or shared library.
> 
> http://www.cmake.org/Bug/view.php?id=1643
> 
> This workaround may help:
> 
> http://www.cmake.org/pipermail/cmake/2006-September/011096.html

 
Thanks for the info.  What a strange feature for CMake to 
lack!  Does anyone know why this hasn't been implemented?

That is, something like

FIND_LIBRARY(... { STATIC_ONLY | SHARED_ONLY | PREFER_STATIC | PREFER_SHARED
} ...)

and/or

ADD_LINK_LIBRARY(... { STATIC_ONLY | SHARED_ONLY | PREFER_STATIC |
PREFER_SHARED } ...)

?

Thanks,
Christian


smime.p7s
Description: S/MIME cryptographic signature
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] .a vs. .so linkage

[Convey Christian J NPRI]

> -Original Message-
> From: Philip Lowman [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 28, 2007 12:15 AM
> To: Convey Christian J NPRI
> Cc: cmake@cmake.org
> Subject: Re: [CMake] Programs linked to .a or .so libraries?
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Convey Christian J NPRI wrote:
> > On Linux, I'm building a program that is linked against the
> "ncurses"
> > library. 
> > 
> > In CMake, what decides whether my program will be linked to 
> > libcurses.a or to libcurses.so ?
> > 
> > I'd like to minimize external dependencies in the build 
program, so 
> > whenever possible I'd like to link to the .a version.  But
> if nothing
> > else I need to know which version (static vs. dynamic) of a given 
> > library my program is linked to.
> 
> This is another one of those things that has not been 
implemented in 
> CMake but which has been brought up before.
> Implementing this on UNIX would be easy but I'm not sure on
> Win32 since you couldn't simply rely on file extension to 
determine if 
> it's a static or shared library.
> 
> http://www.cmake.org/Bug/view.php?id=1643
> 
> This workaround may help:
> 
> http://www.cmake.org/pipermail/cmake/2006-September/011096.html

 
Thanks for the info.  What a strange feature for CMake to 
lack!  Does anyone know why this hasn't been implemented?

That is, something like

FIND_LIBRARY(... { STATIC_ONLY | SHARED_ONLY | PREFER_STATIC | PREFER_SHARED
} ...)

and/or

ADD_LINK_LIBRARY(... { STATIC_ONLY | SHARED_ONLY | PREFER_STATIC |
PREFER_SHARED } ...)

?

Thanks,
Christian


smime.p7s
Description: S/MIME cryptographic signature
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Programs linked to .a or .so libraries?

[Hendrik Sattler]

Am Dienstag 28 August 2007 12:31 schrieb Convey Christian J NPRI:
> Thanks for the info.  What a strange feature for CMake to lack!  Does
> anyone know why this hasn't been implemented?

OTOH, did you ask yourself why you actually want static linking? Sure, your 
program will run that way but only with increased memory usage and load time. 
It's not a good thing to do (that's what APIs and ABIs are for).
If the linker on a system prefers dynamic linking, why do you want to override 
it?

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

RE: [CMake] Programs linked to .a or .so libraries?

[Convey Christian J NPRI]

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] 
> On Behalf Of Hendrik Sattler
> Sent: Tuesday, August 28, 2007 6:46 AM
> To: cmake@cmake.org
> Subject: Re: [CMake] Programs linked to .a or .so libraries?
> 
> Am Dienstag 28 August 2007 12:31 schrieb Convey Christian J NPRI:
> > Thanks for the info.  What a strange feature for CMake to 
> lack!  Does 
> > anyone know why this hasn't been implemented?
> 
> OTOH, did you ask yourself why you actually want static 
> linking? Sure, your program will run that way but only with 
> increased memory usage and load time. 
> It's not a good thing to do (that's what APIs and ABIs are for).
> If the linker on a system prefers dynamic linking, why do you 
> want to override it?
> 

I'm creating installation packages for the software, and we have several
goals:

1) We want to minimize the number of external dependencies required to use
the software, so that installing it requires a minimum of fuss.

2) I'm producing Debian packages for the software, so I need to know which
dynamic libraries my program will need when it is executed.  For example, if
my program has been linked to libFLTK.so, then my Debian package must state
a package-dependency on the libfltk1.1 package.  But if my program has been
linked to libFLTK.a, no such package dependency exists and therefore my own
Debian package shouldn't list libfltk1.1 as a dependency.  Because the
computer that's being used to create the Debian packages might have both
libFLTK.a and libFLTK.so installed on it, I need to control, or at least
know, which version of the FLTK library was linked to my program.


smime.p7s
Description: S/MIME cryptographic signature
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

RE: [CMake] Programs linked to .a or .so libraries?

[Convey Christian J NPRI]

> -Original Message-
> From: Philip Lowman [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, August 28, 2007 12:15 AM
> To: Convey Christian J NPRI
> Cc: cmake@cmake.org
> Subject: Re: [CMake] Programs linked to .a or .so libraries?
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Convey Christian J NPRI wrote:
> > On Linux, I'm building a program that is linked against the 
> "ncurses"
> > library. 
> > 
> > In CMake, what decides whether my program will be linked to 
> > libcurses.a or to libcurses.so ?
> > 
> > I'd like to minimize external dependencies in the build program, so 
> > whenever possible I'd like to link to the .a version.  But 
> if nothing 
> > else I need to know which version (static vs. dynamic) of a given 
> > library my program is linked to.
> 
> This is another one of those things that has not been 
> implemented in CMake but which has been brought up before.  
> Implementing this on UNIX would be easy but I'm not sure on 
> Win32 since you couldn't simply rely on file extension to 
> determine if it's a static or shared library.
> 
> http://www.cmake.org/Bug/view.php?id=1643
> 
> This workaround may help:
> 
> http://www.cmake.org/pipermail/cmake/2006-September/011096.html


Thanks for the info.  What a strange feature for CMake to lack!  Does anyone
know why this hasn't been implemented?

That is, something like

FIND_LIBRARY(... { STATIC_ONLY | SHARED_ONLY | PREFER_STATIC | PREFER_SHARED
} ...)

and/or

ADD_LINK_LIBRARY(... { STATIC_ONLY | SHARED_ONLY | PREFER_STATIC |
PREFER_SHARED } ...)

?

Thanks,
Christian


smime.p7s
Description: S/MIME cryptographic signature
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

RE: [CMake] Programs linked to .a or .so libraries?

[Convey Christian J NPRI]

> > 1) We want to minimize the number of external dependencies 
> required to 
> > use the software, so that installing it requires a minimum of fuss.
> 
> You could provide an additional binary package containing the 
> needed libraries. Extremely easy ;)

I'd like to avoid packaging other projects' software if possible.  It seems
to cause confusion.

> 
> > 2) I'm producing Debian packages for the software, so I 
> need to know 
> > which dynamic libraries my program will need when it is 
> executed.  For 
> > example, if my program has been linked to libFLTK.so, then 
> my Debian 
> > package must state a package-dependency on the libfltk1.1 package.  
> > But if my program has been linked to libFLTK.a, no such package 
> > dependency exists and therefore my own Debian package 
> shouldn't list libfltk1.1 as a dependency.
> 
> Debian packages provide both .a and .so files but GNU ld will 
> prefer the .so file.

A package "libfoo" will typically provide something like "libfoo.so.1.3" and
a symlink "libfoo.so.1".

The package "libfoo-dev" will provide "libfoo.a", and a symlink "libfoo.so"
which points at "libfoo.so.1".

Thanks for the tip about GNU ld.


> 
> > Because the computer that's being used to create the Debian 
> packages 
> > might have both libFLTK.a and libFLTK.so installed on it, I need to 
> > control, or at least know, which version of the FLTK 
> library was linked to my program.
> 
> If you build on Debian, can't you use the dh_shlibdeps with a 
> proper debian/ directory?

Thanks, this is very helpful.  I didn't know about dh_shlibdeps.  While I
still don't have a good way to force my program to be linked against .a
files rather than their .so counterparts, at least I know how to properly
document the package
dependencies now.


smime.p7s
Description: S/MIME cryptographic signature
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Programs linked to .a or .so libraries?

[Hendrik Sattler]

Am Dienstag 28 August 2007 12:55 schrieb Convey Christian J NPRI:
> I'm creating installation packages for the software, and we have several
> goals:
>
> 1) We want to minimize the number of external dependencies required to use
> the software, so that installing it requires a minimum of fuss.

You could provide an additional binary package containing the needed 
libraries. Extremely easy ;)

> 2) I'm producing Debian packages for the software, so I need to know which
> dynamic libraries my program will need when it is executed.  For example,
> if my program has been linked to libFLTK.so, then my Debian package must
> state a package-dependency on the libfltk1.1 package.  But if my program
> has been linked to libFLTK.a, no such package dependency exists and
> therefore my own Debian package shouldn't list libfltk1.1 as a dependency.

Debian packages provide both .a and .so files but GNU ld will prefer the .so 
file.

> Because the computer that's being used to create the Debian packages might
> have both libFLTK.a and libFLTK.so installed on it, I need to control, or
> at least know, which version of the FLTK library was linked to my program.

If you build on Debian, can't you use the dh_shlibdeps with a proper debian/ 
directory?
Otherwise, you can use "objdump -x  | grep NEEDED" to get a list 
of linked libs and look up in /var/lib/dpkg/info/*.shlibs the proper 
dependency for the control file.

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

Re: [CMake] Programs linked to .a or .so libraries?

[Philip Lowman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hendrik Sattler wrote:
> Am Dienstag 28 August 2007 12:31 schrieb Convey Christian J NPRI:
>> Thanks for the info.  What a strange feature for CMake to lack!  Does
>> anyone know why this hasn't been implemented?
> 
> OTOH, did you ask yourself why you actually want static linking? Sure, your 
> program will run that way but only with increased memory usage and load time. 
> It's not a good thing to do (that's what APIs and ABIs are for).
> If the linker on a system prefers dynamic linking, why do you want to 
> override 
> it?

I've never read that shared libraries are faster than static
executables.  One would think that, if anything, all of the hoops the OS
has to run through to map all of the symbols would cause applications
that use shared libraries to be slower to startup then statically built
executables.

As for system memory, a static executable will only use more system
memory if it's using code that other programs are also using at the same
time (libgtk, libxml, etc.).  In that case (and that case only) you
would have multiple programs loading the same symbols into memory and
thus would be wasting system memory.

- --
Philip Lowman
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG1BsDe0tOktX6RKkRAsxiAJwJ/6wnQ/QNmBRewX/um8OqJ1SPxACffc0x
kGoD+1AMi0rHhw/C411B4WI=
=xhwl
-END PGP SIGNATURE-
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Turning on warnings when compiling.

[Michael Wagner]

Hi,

Whenever I'm compiling, there are no warnings shown.
Is there a command or variable that can be used to turn on warnings?

When searching the wiki, the only information I found was this page:
http://www.cmake.org/Wiki/CMake_Platform_Dependent_Issues
which tells me the right flags for all the different compilers. That is
wonderfull, I just need to know how to turn that stuff on!

Maybe somebody out there knows how to turn on warnings. (Hopefully you
are not all fearless coders that laugh in the face of warnings... ;-)

cheers,

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

Re: [CMake] Turning on warnings when compiling.

[Jack Kelly]

Michael Wagner wrote:

Maybe somebody out there knows how to turn on warnings. (Hopefully you
are not all fearless coders that laugh in the face of warnings... ;-)


Real Programmers(tm) don't need warnings!

For mortals like myself, here's how I do it:

Go into the CMake cache via `make edit_cache', `ccmake .' or similar 
from your build directory.


Depending on the value of CMAKE_BUILD_TYPE and the language you're 
using, the variable you'll need to set will be different:


For C, you have CMAKE_C_FLAGS_${CMAKE_BUILD_TYPE} (but in uppercase), so
CMAKE_C_FLAGS
CMAKE_C_FLAGS_DEBUG
CMAKE_C_FLAGS_MINSIZEREL
... and so on

You could also lock down required flags by SETting the variables in 
CMakeLists.txt if you wanted.


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

Re: [CMake] Turning on warnings when compiling.

[James Bigler]

Michael Wagner wrote:

Hi,

Whenever I'm compiling, there are no warnings shown.
Is there a command or variable that can be used to turn on warnings?


I don't know of a specific CMake mechanism to turn on warnings.  I 
figure out which compiler I'm using and turn on flags manually by adding 
the flags to the CMAKE_CXX_FLAGS or something:


##
# Sets some variables depending on which compiler you are using
#
# USING_GCC  : gcc is being used for C compiler
# USING_GPP  : g++ is being used for C++ compiler
# USING_ICC  : icc is being used for C compiler
# USING_ICPC : icpc is being used for C++ compiler

SET(MANTA_COMPILER_NAME_REGEXPR "icc.*$")

IF(NOT CMAKE_COMPILER_IS_GNUCC)
  # This regular expression also matches things like icc-9.1
  IF   (CMAKE_C_COMPILER MATCHES ${MANTA_COMPILER_NAME_REGEXPR})
SET(USING_ICC TRUE)
  ENDIF(CMAKE_C_COMPILER MATCHES ${MANTA_COMPILER_NAME_REGEXPR})
ELSE(NOT CMAKE_COMPILER_IS_GNUCC)
  SET(USING_GCC TRUE)
ENDIF(NOT CMAKE_COMPILER_IS_GNUCC)

#  Do something similar for C++ (see code on line)


## Add flags based on compiler
IF(USING_GCC)
  # to really make this stick, set this as a forced cache variable
  SET(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -Wall)
ENDIF(USING_GCC)

--
You might also want to add code to only set the flags on the first 
configure.  This allows users to remove flags you have set by default.


You can see the code here:
https://code.sci.utah.edu/svn/Manta/trunk/CMake/CompilerInfo.cmake
https://code.sci.utah.edu/svn/Manta/trunk/CMake/ConfigCompilerFlags.cmake

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

Re: [CMake] Programs linked to .a or .so libraries?

[Hendrik Sattler]

Am Dienstag 28 August 2007 14:54 schrieb Philip Lowman:
> Hendrik Sattler wrote:
> > Am Dienstag 28 August 2007 12:31 schrieb Convey Christian J NPRI:
> >> Thanks for the info.  What a strange feature for CMake to lack!  Does
> >> anyone know why this hasn't been implemented?
> >
> > OTOH, did you ask yourself why you actually want static linking? Sure,
> > your program will run that way but only with increased memory usage and
> > load time. It's not a good thing to do (that's what APIs and ABIs are
> > for). If the linker on a system prefers dynamic linking, why do you want
> > to override it?
>
> I've never read that shared libraries are faster than static
> executables.  One would think that, if anything, all of the hoops the OS
> has to run through to map all of the symbols would cause applications
> that use shared libraries to be slower to startup then statically built
> executables.

But there are big libs once in a while that need some time to load itself.
Just imagine static version of skype that uses QT. In an environment that also 
uses those libs, e.g. KDE, the startup time for the application is extremely 
slow. Personal experience, here.
And you also have a disk buffer, so that with two different applications, that 
do share a library but do not run at the same time, gain from using a shared 
library.

> As for system memory, a static executable will only use more system
> memory if it's using code that other programs are also using at the same
> time (libgtk, libxml, etc.).  In that case (and that case only) you
> would have multiple programs loading the same symbols into memory and
> thus would be wasting system memory.

Well, a statically linked program may even consume less memory (and may load 
faster) if it only uses a subset of a library and the linker does it right. 
However, with more than one program, the chances go down very fast that 
static linking is a good choice.

But it's also a security nightmare: you cannot just update the lib, you also 
have to relink the program.

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

Re: [CMake] Programs linked to .a or .so libraries?

[gga]

Philip Lowman wrote:

I've never read that shared libraries are faster than static
executables.  One would think that, if anything, all of the hoops the OS
has to run through to map all of the symbols would cause applications
that use shared libraries to be slower to startup then statically built
executables.


The mapping happens pretty much automatically as it is usually done by 
an indirect table.
This indirect table does add some overhead to runtime execution, but 
with current machines this is negligible.


Loading all the code for a library can take some time (some seconds or 
minutes), even with today's machines.


If the same shared library is used by multiple programs, loading the 
code in memory needs to happen only once.
With static libraries, you always have to load the code regardless and 
as you say, you keep several copies of the same or similar code in memory.


Most modern OSes also support the concept of delay loaded dsos.  That 
is, shared dso files which are loaded only when a function to them is 
referenced, not just at startup of the executable.  This allows an 
executable to be linked to a shared library but not have to load it 
unless the user actually uses a function belonging to the dso.  There's 
no way to do that with static linking.


Good OSes like linux will also often cache the access to shared 
libraries, making reopening the same .so several times almost immediate. 
 Static executables are hardly ever cached.


If you are also loading a library already used by your window manager 
(usually some KDE or Gnome library on linux these days, but also some 
other common libs like libz, libpng, etc), the shared library will 
probably not even need to be loaded at all, as the window manager 
already did it for you.   Again, with static linking you loose that.


All those benefits can lead a program using shared libraries to start up 
faster than if it had been linked statically.  Of course, this does not 
mean it will indeed do so, just that it may.



--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Changing the default name "CMakeLists.txt"

[Bill Hoffman]

Dizzy wrote:

On Tuesday 28 August 2007 12:05:49 Martin Lütken wrote:
  

If not, then does anyone have an idea how hard it would be to add a
possiblity (command line option I guess) like that to the cmake source code
?



From a simple grep in the cmake CVS sources I think that to add such an option 
first would require to have a unified place with the "CMakeLists.txt" string 
value because currently there are about 15 different places in code where the 
string is hardcoded, about 30 places where it appears in messages generated 
from the code and A LOT of code comments and cmake module comments where it's 
used (tho the comments can be left in place since they still make sense 
talking about a CMakeLists.txt file even if that is configurable).


All in all I don't think it's very hard to do it, would result in a better 
cmake code organization too (not having scattered "CMakeLists.txt" magic 
value all over the code).


  
It would also have to be propagated into the rules that re-run cmake 
when things change.  I have yet

to see a good reason to do this.

-Bill

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

RE: [CMake] Turning on warnings when compiling.

[Sanchez, Juan]

ADD_DEFINITIONS(-Wall)

should work for both the gnu c and c++ compiler and other compilers supporting 
gnu option emulation.

You can also do:
make VERBOSE=1

on a unix system to see the commands being executed.

Regards,

Juan


-Original Message-
From: [EMAIL PROTECTED] on behalf of Michael Wagner
Sent: Tue 8/28/2007 8:07 AM
To: cmake@cmake.org
Subject: [CMake] Turning on warnings when compiling.
 
Hi,

Whenever I'm compiling, there are no warnings shown.
Is there a command or variable that can be used to turn on warnings?

When searching the wiki, the only information I found was this page:
http://www.cmake.org/Wiki/CMake_Platform_Dependent_Issues
which tells me the right flags for all the different compilers. That is
wonderfull, I just need to know how to turn that stuff on!

Maybe somebody out there knows how to turn on warnings. (Hopefully you
are not all fearless coders that laugh in the face of warnings... ;-)

cheers,

Michael
___
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

Re: [CMake] Programs linked to .a or .so libraries?

[Jack Kelly]

Hendrik Sattler wrote:
But it's also a security nightmare: you cannot just update the lib, you also 
have to relink the program.


Another reason: you can't statically link against GNU LGPL code without 
getting into a huge mess of sending out half-linked binaries so that 
users still have the freedom to modify the LGPL part of the code and 
link it against your static work.


(I know that the OP wasn't talking about LGPL code, but I thought I'd 
throw it out there as a reason why I don't think it's so great an idea)


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

[CMake] Re: Sharing code between projects

[Matthew Woehlke]

kitts wrote:
Anyway, I have a new set of projects and my current problem is that i have 
some code that i share between projects. Once source can be shared not 
binaries.


Code is organized as;
src/common
src/project1
src/project2

The CMakeLists.tst files are located inside for each project which sets the 
right compiler and sources to be built. Now i want common to be included in 
each of these proejects and build separately for each by inheriting all the 
settings for that project.


What is the best way to achieve this? I cant use ADD_SUBDIRECTORY() as it is 
really a sibling folder (cmake complains if I use "../common").


The way I did this was to use the somewhat dubious solution:

IF(PROJECT STREQUALS FOO)
  ADD_DIRECTORY(foo)
ELSEIF(PROJECT STREQUAL BAR)
  ADD_DIRECTORY(bar)
ELSE(PROJECT STREQUALS FOO)
  MESSAGE(FATAL_ERROR "You didn't tell me what PROJECT to build!")
ENDIF(PROJECT STREQUALS FOO)

...and then, obviously, add e.g. '-DPROJECT:STRING=FOO' to your initial 
cmake run.


My source tree looks like:

build-foo/
build-bar/
src/
  common/
  foo/
  bar/

--
Matthew
"What, more work?" -- Peasants (Warcraft II)

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

Re: [CMake] Re: Sharing code between projects

[kitts]

On Tuesday 28 Aug 2007 9:10:47 pm Matthew Woehlke wrote:
> The way I did this was to use the somewhat dubious solution:
>
> IF(PROJECT STREQUALS FOO)
>    ADD_DIRECTORY(foo)
> ELSEIF(PROJECT STREQUAL BAR)
>    ADD_DIRECTORY(bar)
> ELSE(PROJECT STREQUALS FOO)
>    MESSAGE(FATAL_ERROR "You didn't tell me what PROJECT to build!")
> ENDIF(PROJECT STREQUALS FOO)
>
> ...and then, obviously, add e.g. '-DPROJECT:STRING=FOO' to your initial
> cmake run.
>
> My source tree looks like:
>
> build-foo/
> build-bar/
> src/
>    common/
>    foo/
>    bar/

This is interesting. I am still thinking of something such because by 
generating a KDevelop3 project (or doing it manually), KDevelop refuses to 
add the common folder sources as part of the project. KDevelop becomes simply 
an editor around these files and does not offer all goodies such as code 
completion, code navigation, documentation etc.

I didn't want to bring in an unintuitive directory structure to aid this. 
Still confused! :-)
-- 
Cheers!
kitts
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] New compiler module for Digital Mars' D language -- one problem remains!

[Tim Burrell]

Hi there,

I'm currently working on a compiler module for CMake for the D
programming language, and so far it's worked quite well, with one exception:

The digital mars linker _requires_ that TARGET_LINK_LIBRARY paths have a
trailing slash on them.  To make matters worse it uses the same command
line switch for both link library paths and link libraries (it
differentiates between them via the trailing slash).

So far as I can tell CMake strips trailing slashes, and there doesn't
appear to be a way to force it not to do this, or to add a trailing
slash onto the library path.

Is there actually a way to do this, and I'm just missing it?  If not,
could this be included as a feature?  Maybe something like:

SET(CMAKE_LIBRARY_PATH_FLAG_TERMINATOR "/") # or "" for none

This would be great!  (I actually don't really care how it's
implemented, I'd just like a way to make it happen).

Thanks,

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

Re: [CMake] New compiler module for Digital Mars' D language -- one problem remains!

[Alexander Neundorf]

On Tuesday 28 August 2007 12:02, Tim Burrell wrote:
> Hi there,
>
> I'm currently working on a compiler module for CMake for the D
> programming language, and so far it's worked quite well, with one
> exception:
>
> The digital mars linker _requires_ that TARGET_LINK_LIBRARY paths have a
> trailing slash on them.  To make matters worse it uses the same command
> line switch for both link library paths and link libraries (it
> differentiates between them via the trailing slash).
>
> So far as I can tell CMake strips trailing slashes, and there doesn't
> appear to be a way to force it not to do this, or to add a trailing
> slash onto the library path.
>
> Is there actually a way to do this, and I'm just missing it?  If not,
> could this be included as a feature?  Maybe something like:
>
> SET(CMAKE_LIBRARY_PATH_FLAG_TERMINATOR "/") # or "" for none
>
> This would be great!  (I actually don't really care how it's
> implemented, I'd just like a way to make it happen).

Please try the attached patch for cmLocalGenerator.cxx, it is against current 
cvs and add something like
SET(CMAKE_LIBRARY_PATH_TERMINATOR "/")
to the cmake files for D.

Let me know if that works for you.

Bye
Alex
Index: cmLocalGenerator.cxx
===
RCS file: /cvsroot/CMake/CMake/Source/cmLocalGenerator.cxx,v
retrieving revision 1.235
diff -b -u -p -r1.235 cmLocalGenerator.cxx
--- cmLocalGenerator.cxx	21 Aug 2007 20:22:55 -	1.235
+++ cmLocalGenerator.cxx	28 Aug 2007 17:01:31 -
@@ -1531,6 +1531,8 @@ void cmLocalGenerator::OutputLinkLibrari
 }
   std::string libPathFlag = 
 this->Makefile->GetRequiredDefinition("CMAKE_LIBRARY_PATH_FLAG");
+  std::string libPathTerminator = 
+this->Makefile->GetSafeDefinition("CMAKE_LIBRARY_PATH_TERMINATOR");
   std::string libLinkFlag = 
 this->Makefile->GetSafeDefinition("CMAKE_LINK_LIBRARY_FLAG");
   // collect all the flags needed for linking libraries
@@ -1599,6 +1601,7 @@ void cmLocalGenerator::OutputLinkLibrari
 {
 linkLibs += libPathFlag;
 linkLibs += fullLibPath;
+linkLibs += libPathTerminator;
 linkLibs += " ";
 
 // Put this directory in the rpath if using build-tree rpath
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Using fluid, fltk, cmake and own headers

[Atwood, Robert C]

Hi, 
I have a bit of a problem, which I can work around but would rather not
have to... I am using FLUID to make a FLTK interface, at this point just
to read some data into a customized structure. The structure definition
is in my header file 'eletable.h' in the source directory. The FLUID
file is called 'tabinter.fl' 

I am attempting to do this by including an 'eletable' as a member of a
class, added by using the fluid program. To do this I added code 
#include "eletable.h" 

Using the Fluid menu. 

However, when I try to make the project with cmake, the tabinter.{cxx,h}
files are generated in the build directory, and the compiler cannot then
seem to locate the source directory where the 'eletable.h' file is
located. 

It builds correctly if the project is built IN the source tree. However,
due to using ITK and friends I have gotten to prefer building outside
the source tree if possible. 
How can the step which compiles the .cxx and .h file generated by FLUID
be set to include the source tree, whatever it is? I can include the
path manually but that does not help if for example, the files are
stored in a directory with a different name. 
Thanks for any advice
Robert



Here's my CmakeLists.txt file

PROJECT(WIRS)

FIND_PACKAGE(FLTK)
IF(FLTK_FOUND)
  INCLUDE_DIRECTORIES(${FLTK_INCLUDE_DIR})
ENDIF(FLTK_FOUND)


FLTK_WRAP_UI(wirs tabinter.fl)
ADD_EXECUTABLE(wirs  ${wirs_FLTK_UI_SRCS} wirsMain.cxx calcweights.cxx
element.cxx eletable.cxx etable.cxx readdata.cxx)

TARGET_LINK_LIBRARIES(wirs  fltk)


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

Re: [CMake] New compiler module for Digital Mars' D language -- one problem remains!

[Tim Burrell]

Hi Alexander,

Thanks very much for the patch!  This does exactly what I needed!  I
just finished testing and the D module is now working great on all
platforms and compilers finally.

Will this patch make it into CVS and eventually an upcoming CMake release?

I'm also curious, what would it take to get the D modules into the
default CMake install?  Of course I would be willing to take
maintainership of them.

If anyone is curious they can be viewed here:
http://svn.dsource.org/projects/cmaked/trunk/cmaked/

Current homepage is here: http://www.dsource.org/projects/cmaked/wiki

Thanks again,

Tim.

Alexander Neundorf wrote:
> On Tuesday 28 August 2007 12:02, Tim Burrell wrote:
>> Hi there,
>>
>> I'm currently working on a compiler module for CMake for the D
>> programming language, and so far it's worked quite well, with one
>> exception:
>>
>> The digital mars linker _requires_ that TARGET_LINK_LIBRARY paths have a
>> trailing slash on them.  To make matters worse it uses the same command
>> line switch for both link library paths and link libraries (it
>> differentiates between them via the trailing slash).
>>
>> So far as I can tell CMake strips trailing slashes, and there doesn't
>> appear to be a way to force it not to do this, or to add a trailing
>> slash onto the library path.
>>
>> Is there actually a way to do this, and I'm just missing it?  If not,
>> could this be included as a feature?  Maybe something like:
>>
>> SET(CMAKE_LIBRARY_PATH_FLAG_TERMINATOR "/") # or "" for none
>>
>> This would be great!  (I actually don't really care how it's
>> implemented, I'd just like a way to make it happen).
> 
> Please try the attached patch for cmLocalGenerator.cxx, it is against current 
> cvs and add something like
> SET(CMAKE_LIBRARY_PATH_TERMINATOR "/")
> to the cmake files for D.
> 
> Let me know if that works for you.
> 
> Bye
> Alex
> 
> 
> 
> 
> ___
> 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

Re: [CMake] Using fluid, fltk, cmake and own headers

[Jack Kelly]

Atwood, Robert C wrote:

However, when I try to make the project with cmake, the tabinter.{cxx,h}
files are generated in the build directory, and the compiler cannot then
seem to locate the source directory where the 'eletable.h' file is
located. 


Hi Robert,

Here's what I'd add to your CMakeLists.txt:

1.
INCLUDE_DIRECTORIES(${WIRS_BUILD_DIR}/path/to/.{cxx|h}) as appropriate. 
Perhaps in a macro that calls ADD_CUSTOM_COMMAND so you don't have to 
update it.


2.
Try specifying the generated sources as
${WIRS_BINARY_DIR}/${wirs_FLTK_UI_SRCS}

I couldn't find a definition of FLTK_WRAP_UI in my CMake install, so I'm 
not 100% on how it works.


3.
You may need to mark the source files as generated, if something else 
isn't doing so already. Here's how:


SET_SOURCE_FILES_PROPERTIES("${WIRS_BINARY_DIR}/${wirs_FTLK_UI_SRCS}" 
PROPERTIES GENERATED TRUE)


I hope that's of some use to you.

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

Re: [CMake] Using fluid, fltk, cmake and own headers

[Alexander Neundorf]

On Tuesday 28 August 2007 14:33, Atwood, Robert C wrote:
> This seems to work (not quite as you suggest but similar)
>
> > 1.
> > INCLUDE_DIRECTORIES(${WIRS_BUILD_DIR}/path/to/.{cxx|h}) as
> > appropriate.
>
> You mean ${WIRS_SOURCE_DIR} ... and that seems to work but I am still
> puzzled why it is not included by default, it seems logical that your
> own source dir should be included during the build process.

You can add the following to your toplevel CMakeLists.txt:
SET(CMAKE_INCLUDE_CURRENT_DIR TRUE)
then the current source and the current binary dir are always include search 
paths.
make.org/Wiki/CMake_Useful_Variables#Various_Options

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

[CMake] Visual Studio reload projects

[KSpam]

One major annoyance that users have with CMake integration in VisualStudio is 
having to click "Yes" to reload the project files after CMake regenerates 
them.  There is no "Yes to All" option.  With hundreds of projects, it takes 
a while to click all of the "Yes" buttons.

Does anyone know if there is a way to force the reload in Visual Studio, so 
that the user is not bothered with the dialog boxes?  Is there a 
configuration option in Visual Studio?

I tell the users to exit Visual Studio, reconfigure CMake, and then reopen 
Visual Studio, but that is a suboptimal solution.

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

RE: [CMake] Using fluid, fltk, cmake and own headers

[Atwood, Robert C]

This seems to work (not quite as you suggest but similar) 


> 1.
> INCLUDE_DIRECTORIES(${WIRS_BUILD_DIR}/path/to/.{cxx|h}) as 
> appropriate. 

You mean ${WIRS_SOURCE_DIR} ... and that seems to work but I am still
puzzled why it is not included by default, it seems logical that your
own source dir should be included during the build process. 


Many thanks!
Robert


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

RE: [CMake] Using fluid, fltk, cmake and own headers

[Atwood, Robert C]

> You can add the following to your toplevel CMakeLists.txt:
> SET(CMAKE_INCLUDE_CURRENT_DIR TRUE)

Yes, that's just what I want ! Thannks

> make.org/Wiki/CMake_Useful_Variables#Various_Options

That site's a bit scary, I'll stick with cmake.org for now!
;-/
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] New compiler module for Digital Mars' D language -- one problem remains!

[Alexander Neundorf]

On Tuesday 28 August 2007 13:38, you wrote:
> Hi Alexander,
>
> Thanks very much for the patch!  This does exactly what I needed!  I
> just finished testing and the D module is now working great on all
> platforms and compilers finally.
>
> Will this patch make it into CVS and eventually an upcoming CMake release?

Done. It will be in cmake 2.6.0.

> I'm also curious, what would it take to get the D modules into the
> default CMake install?  Of course I would be willing to take
> maintainership of them.

That and one or more tests in CMake/Tests/ so it can be tested every night.

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

Re: [CMake] Visual Studio reload projects

[Andrew Maclean]

>From memory, I am pretty sure that this is a Visual Studio issue.
I agree that it is a pain but I think the solution outlined below is the
only one.


On 8/29/07, KSpam <[EMAIL PROTECTED]> wrote:
>
> One major annoyance that users have with CMake integration in VisualStudio
> is
> having to click "Yes" to reload the project files after CMake regenerates
> them.  There is no "Yes to All" option.  With hundreds of projects, it
> takes
> a while to click all of the "Yes" buttons.
>
> Does anyone know if there is a way to force the reload in Visual Studio,
> so
> that the user is not bothered with the dialog boxes?  Is there a
> configuration option in Visual Studio?
>
> I tell the users to exit Visual Studio, reconfigure CMake, and then reopen
> Visual Studio, but that is a suboptimal solution.
>
> Thanks,
> Justin
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>



-- 
___
Andrew J. P. Maclean
Centre for Autonomous Systems
The Rose Street Building J04
The University of Sydney  2006  NSW
AUSTRALIA
Ph: +61 2 9351 3283
Fax: +61 2 9351 7474
URL: http://www.acfr.usyd.edu.au/
___
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Turning on warnings when compiling.

[Andrew Maclean]

I do something like this (I think it was taken from the VTK CmakeLists.txtfile):

#-
# Let's use the highest warning level.
#-
IF(CMAKE_BUILD_TOOL MATCHES "(msdev|devenv|nmake)")
  # Use the highest warning level for visual studio.
  IF(CMAKE_CXX_FLAGS MATCHES "/W[0-4]")
STRING(REGEX REPLACE "/W[0-4]" "/W4" CMAKE_CXX_FLAGS
"${CMAKE_CXX_FLAGS}")
  ELSE(CMAKE_CXX_FLAGS MATCHES "/W[0-4]")
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /W4")
  ENDIF(CMAKE_CXX_FLAGS MATCHES "/W[0-4]")
  IF(CMAKE_C_FLAGS MATCHES "/W[0-4]")
STRING(REGEX REPLACE "/W[0-4]" "/W4" CMAKE_C_FLAGS "${CMAKE_C_FLAGS}")
  ELSE(CMAKE_C_FLAGS MATCHES "/W[0-4]")
SET(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} /W4")
  ENDIF(CMAKE_C_FLAGS MATCHES "/W[0-4]")
  # Disable deprecation warnings for standard C functions in VS2005 and
later
  IF(CMAKE_COMPILER_2005)
ADD_DEFINITIONS(-D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE)
  ENDIF(CMAKE_COMPILER_2005)
ENDIF(CMAKE_BUILD_TOOL MATCHES "(msdev|devenv|nmake)")
IF(CMAKE_BUILD_TOOL MATCHES "make")
  IF(NOT CMAKE_CXX_FLAGS MATCHES "-Wall")
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall")
  ENDIF(NOT CMAKE_CXX_FLAGS MATCHES "-Wall")
  IF(NOT CMAKE_C_FLAGS MATCHES "-Wall")
SET(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wall")
  ENDIF(NOT CMAKE_C_FLAGS MATCHES "-Wall")
ENDIF(CMAKE_BUILD_TOOL MATCHES "make")


Andrew




On 8/28/07, Michael Wagner <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> Whenever I'm compiling, there are no warnings shown.
> Is there a command or variable that can be used to turn on warnings?
>
> When searching the wiki, the only information I found was this page:
> http://www.cmake.org/Wiki/CMake_Platform_Dependent_Issues
> which tells me the right flags for all the different compilers. That is
> wonderfull, I just need to know how to turn that stuff on!
>
> Maybe somebody out there knows how to turn on warnings. (Hopefully you
> are not all fearless coders that laugh in the face of warnings... ;-)
>
> cheers,
>
> Michael
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>



-- 
___
Andrew J. P. Maclean
Centre for Autonomous Systems
The Rose Street Building J04
The University of Sydney  2006  NSW
AUSTRALIA
Ph: +61 2 9351 3283
Fax: +61 2 9351 7474
URL: http://www.acfr.usyd.edu.au/
___
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] New compiler module for Digital Mars' D language -- one problem remains!

[Tim Burrell]

Hey Alexander,

>> Will this patch make it into CVS and eventually an upcoming CMake release?
> 
> Done. It will be in cmake 2.6.0.

Excellent!  Thanks again for the quick work on this.

>> I'm also curious, what would it take to get the D modules into the
>> default CMake install?  Of course I would be willing to take
>> maintainership of them.
> 
> That and one or more tests in CMake/Tests/ so it can be tested every night.

I have no problem creating some test cases however the D compiler module
is a bit complicated.  It supports two different compilers, and two
different standard library sets (which are incompatible with each
other).  I'm curious how automated testing might work.  Would there be a
machine that would get the D compilers loaded onto?

I could come up with a test example that will compile with both standard
libraries, and if both compilers were set up on the test machine, each
compiler could be set up to use a specific standard library.

I'm not sure how rigorous the tests should be, if it's enough to know
one compiler and one library passes a test this should be relatively
easy, but if every case needs to be covered this may require an overly
complex solution.

Any thoughts on this?

Thanks,

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

Re: [CMake] Visual Studio reload projects

[KSpam]

I agree that this is a Visual Studio issue; however, I am wondering if anyone 
knows a workaround.  I am not a Windows developer, but I figured that someone 
on this list would have found a reasonable solution.

On Tuesday 28 August 2007 16:18:34 Andrew Maclean wrote:
> From memory, I am pretty sure that this is a Visual Studio issue.
> I agree that it is a pain but I think the solution outlined below is the
> only one.
>
> On 8/29/07, KSpam <[EMAIL PROTECTED]> wrote:
> > One major annoyance that users have with CMake integration in
> > VisualStudio is
> > having to click "Yes" to reload the project files after CMake regenerates
> > them.  There is no "Yes to All" option.  With hundreds of projects, it
> > takes
> > a while to click all of the "Yes" buttons.
> >
> > Does anyone know if there is a way to force the reload in Visual Studio,
> > so
> > that the user is not bothered with the dialog boxes?  Is there a
> > configuration option in Visual Studio?
> >
> > I tell the users to exit Visual Studio, reconfigure CMake, and then
> > reopen Visual Studio, but that is a suboptimal solution.
> >
> > Thanks,
> > Justin
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake