[CMake] Proposal for fixing DESTDIR and absolute installed files for DEB and RPM

2010-08-23 Thread Eric Noulard
Hi All,

I've just updated a proposal for fixing the long running issue:
http://public.kitware.com/Bug/view.php?id=7000

Patches are on the tracker of changes may be pulled from:
http://github.com/TheErk/CMake/tree/CPack-FixDESTDIR-Issue7000


-- 
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] Visual Studio Generator: different Link paths for Debug and Release

2010-08-25 Thread Eric Noulard
2010/8/25  :
> Hi all.
>
>
>
> I need to use different link paths for Debug and Release builds of my
> software.  I’m building with the Visual Studio Generator (2005, 2008, etc).
> I had put this in my CMakeLists.txt, but as it turns out, this doesn’t do
> what I need (likely because of the single pass to generate the project
> files):
>
>
>
> if(DEBUG)
>
>  link_directories("$ENV{RDFD3RDPARTYDIR}/lib/Debug")
>
> else()
>
>  link_directories("$ENV{RDFD3RDPARTYDIR}/lib/Release")
>
> endif()

I wouldn't use link_directories but

target_link_libraries(
 debug $ENV{RDFD3RDPARTYDIR}/lib/Debug/whateverlib
 optimized
$ENV{RDFD3RDPARTYDIR}/lib/Release/whateverlib )


> So, my question: is there a way to have different link directory paths for
> each configuration in visual studio without generating multiple build
> directories for VS?

I think target_link_libraries with full path to lib is preferred to
link_directories + target_link_libraries with no path.



-- 
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] running python tests

2010-08-25 Thread Eric Noulard
2010/8/25 David Cole :
> Show us your "add_test" call.
> If it's a python script, execute the python interpreter and pass the script
> as an arg:
> add_test(${PYTHON_EXECUTABLE} "/full/path/to/script.py")

I think you mean

add_test(TestName ${PYTHON_EXECUTABLE} "/full/path/to/script.py")

Another solution I'm currently using on Linux
(don't know how it work on Windows) is to add
this as the very first line of your script:

#!/usr/bin/env python

+ making the script executable.

Then
add_test(TestName "/full/path/to/script.py")
should work as well without trouble.

David's solution should work on Windows too as soon as you
find_package(PythonInterp)

see
http://docs.python.org/tutorial/interpreter.html#executable-python-scripts
-- 
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] CMake & OCaml

2010-08-25 Thread Eric Noulard
2010/8/25 Magnus Therning :
> A while ago I started looking at using CMake to build OCaml projects.  As part
> of that I put together some useful (but maybe not very beautiful) macros.
> They are available on github[1].
>
> I've come to the conclusion that while CMake is a rather good build tool, it
> isn't very well designed to add full support for slightly esoteric languages
> and tool chains like OCaml.

I'm no OCaml expert but I'd like to know how you decided to build
your OCaml project then?
using ocamlbuild? custom makefiles ?

May be you can give us here a the "main" 3 or so reasons
you think CMake cannot handle OCaml project building.

It may be useful for other not to go through the same path
you did.

-- 
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] Visual Studio Generator: different Link paths for Debug and Release

2010-08-25 Thread Eric Noulard
2010/8/25  :
> Ok, I'll give that a shot.  I wonder if I could iterate the list of targets 
> and make the target_link_libraries() calls on them in a loop.

You can do that.

However I am not aware of a way to get the list of targets
from within a CMakeLists.txt with some cmake command or property.

If you set up your list of target "yourself" then the loop
should works.


-- 
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] CMake & OCaml

2010-08-25 Thread Eric Noulard
2010/8/25 Alan W. Irwin :
> On 2010-08-25 17:50+0200 Eric Noulard wrote:
>
>> 2010/8/25 Magnus Therning :
>>>
>>> A while ago I started looking at using CMake to build OCaml projects.  As
>>> part
>>> of that I put together some useful (but maybe not very beautiful) macros.
>>> They are available on github[1].
>>>
>>> I've come to the conclusion that while CMake is a rather good build tool,
>>> it
>>> isn't very well designed to add full support for slightly esoteric
>>> languages
>>> and tool chains like OCaml.
>>
>> I'm no OCaml expert but I'd like to know how you decided to build
>> your OCaml project then?
>> using ocamlbuild? custom makefiles ?
>>
>> May be you can give us here a the "main" 3 or so reasons
>> you think CMake cannot handle OCaml project building.
>>
>> It may be useful for other not to go through the same path
>> you did.
>
> Look at my post (which crossed yours) for some of the ocaml issues we
> encountered in the PLplot project.  In short, the detailed
> custom-command/custom-target approach works, but many different kinds
> of build commands are involved (much more than the "normal" compile
> and link)

Read your answer with interest and was about to answer too :-)

[...]
> It is possible somebody with knowledge of the internals of CMake could
> change things around so that the configurable commands to build
> libraries could be a whole set of detailed custom commands and targets
> specified at the language support level.

[...]

I was about to propose such "trapped" extension to language support.
Take my words with "[double]-quotes" because I have not enough knowledge
of that part (language support) of CMake.

My ideas was that some languages:
- OCaml   (ocamlbuild)
- ADA  (gnatmake)
- may Java too (ant/maven)

have already very efficient build tool with some history of usage too.
I don't know many Java developers who speaks "makefile", most
of them speak "Eclipse/Netbeans" and many of them ant (http://ant.apache.org/)
what would be the advantage to go for CMake?

Most of those tools are already cross-platform and they are pretty
efficient (Ant for example is very handy and includes a plugins system
which makes it easy to extend for doing fancy things)
with a good user base.

My point is I don't think it would be useful (for me) to have some
Java/Ocaml/...
builtin support in CMake, because:
   1) I would have to port already working nice build systems
   2) I would have to argue with other on why they would learn CMake
   they don't need because they are only concerned with the Java part.

However I may have some project with mixed "classical compiled+linked languages"
like C/C++/Fortran with some interface/plugins in "not classically
compiled+linked"
Java/OCaml etc...
(looks like the PLplot layout) I'd expect to be able to build
all those thing with.

cmake
make
make package (or make install)

I suggest some language plugins support for CMake which makes it possible
to weave "native" build tools (ant, ocamlbuild, gnatmake) with CMake
control build.

I think this may be more than set of "custom command model" I would want
something like "generic (or specific) build tool interface"

CMake should know about
   sources (directories and files)
   dependencies
   targets

I may do something like:

find_delegate_builtool(Ant)

if (Ant_TOOL_FOUND)
   add_delegated_target(TARGETS JavaPlug1 JavaPlug2
   SOURCES  jsrc1 jsrc2 build1.xml build2.xml
   BUILD_COMMAND ${Ant_TOOL} all
   CHECKDEP_COMMAND ${Ant_TOOL} all
   CLEAN_COMMAND ${Ant_TOOL} clean
   GETOUTPUTS_COMMAND ${Ant_TOOL} getoutput)
endif(Ant_TOOL_FOUND)

the "delegate build tool" would be responsible for building targets
with "BUILD_COMMAND" and "CHECKDEP_COMMAND" for checking dependencies
SOURCES specifies the list of sources (inputs for the BUIDL TOOL).
"GETOUTPUTS_COMMAND" may be used by CMake to get the list
of may be file/dir produced by the build tool.
the "CLEAN_COMMAND" may be used to clean that part of the project.

This could be something like "ExternalProject_Add"
but may be renamed to "ForeignLanguageProject_Add" :-)

> Do the CMake developers here like the idea of this type of
> generalization of the CMake language support?

Same question for me :-)

-- 
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] Cmake with wxWidgets ribbons

2010-08-30 Thread Eric Noulard
2010/8/30 assume_R :
> Hello.  First post to the mailing list.  Just thought I'd share a bug I
> found and fixed.
> The new version of wxWidgets (>= 2.9) contains a "ribbons" library, which
> emulates the ribbon UI of MS Office and newer Windows 7 applications
> (http://en.wikipedia.org/wiki/Ribbon_(computing)).
> However, the FindwxWidgets.cmake file in the "Modules" directory of cmake
> needs to have the following modifications for the ribbons library to work:
> 1. Line 306 "FOREACH(LIB core adv aui html media xrc dbgrid gl qa richtext)"
> Should change to "FOREACH(LIB core adv aui html media xrc dbgrid gl qa
> richtext ribbon)"
> 2. Line 347 "FOREACH(LIB core adv aui html media xrc dbgrid gl qa richtext)"
> Should change to "FOREACH(LIB core adv aui html media xrc dbgrid gl qa
> richtext ribbon)"
> Then, you can simply type "find_package (wxWidgets REQUIRED base core
> ribbon)" in your CMakeLists.txt file, for example, to add the ribbon UI to
> your cmake-handled project!
> Hope this helps someone, and hopefully this can be added to the next version
> of cmake!  I wasn't sure if I should have submitted a bug report or not,
> since it would be immediately opened and closed.

You can check who is the maintainer of this module there:
http://www.cmake.org/Wiki/CMake:Module_Maintainers
he/she should usually be subscribed to the list but

if ever you do not get any feedback, "after some times",
may be a gentle direct e-mail with a patch attached would
be a good way be sure your feedback is taken into account.

-- 
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] Conditional compiling [i.e. OpenMP]

2010-08-31 Thread Eric Noulard
2010/8/31 Raymond Wan :
>
> #
> FIND_PACKAGE (OpenMP)
>
> if (OPENMP_FOUND)
>  SET (HAVE_OPENMP 1)
>  SET (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${OpenMP_CXX_FLAGS}")
> endif()
> #
>
> and then created a "config.hpp.in" which had this:
>
> #cmakedefine HAVE_OPENMP 1
>
> config.hpp gets generated fine, but it ends up having this:
>
> /* #undef HAVE_OPENMP */
> I can confirm that OpenMP is being detected because I can see the
> various values being defined in CMakeCache.txt.  HAVE_OPENMP is not in
> this file, though (it should, I presume?).

HAVE_OPENMP is not in CMakeCache.txt because you did not defined
it to be a cache var.

However, I don't think HAVE_OPENMP have to be a cache var for this to work.

We are missing your CONFIGURE_FILE statement how does it look like?
May be you can try a simple test:

set(OPENMP_FOUND 1)

if (OPENMP_FOUND)
   SET (HAVE_OPENMP 1)
   SET (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${OpenMP_CXX_FLAGS}")
endif()

configure_file(${CMAKE_CURRENT_SOURCE_DIR}/config.hpp.in
${CMAKE_CURRENT_BINARY_DIR}/config.hpp)

with your current config.hpp.in.

If this does not generate the appropriate config.hpp file then
send this minimal project (CMakeLists.txt + config.hpp.in) on the list.


Which version of CMake are you using?
What is your platform (Linux, Windows, MacOS...)

-- 
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] Would it be possible to have cmake make final binaries?

2010-08-31 Thread Eric Noulard
2010/8/31 David Cole :
> Steps 7 thru 10 on your list may be performed by the command lines:
>   cmake --build . --config Release
>   cmake --build . --target install --config Release
>   (equivalent to the "make; make install" parts of your example command
> line)
> Causing that to happen in delicious GUI form would be simple enough... But
> do enough people want this...?

Speaking for a one-line install (or buid package) command
using CMake would be nice.

I did craft one small (not bulletproof at all) CMake script
which can be called as

$ cmake -P CMake-autoinstall.cmake
-- Trying to autoinstall CMake version  using
http://www.cmake.org/files/v2.8/cmake-2.8.2.tar.gz file...
-- Downloading...
-- Already there: nothing to do
-- Unarchiving the file
-- CMake version 2.8.2 has been unarchived in /home/eric/CMake/tmp/cmake-2.8.2.
-- Configuring with CMake...
-- Building with cmake --build ...
-- Create package RPM with CPack...
-- CMake version 2.8.2 has been built in /home/eric/CMake/tmp/cmake-2.8.2.
-- CMake package(s) are:
/home/eric/CMake/tmp/cmake-2.8.2-build/cmake-2.8.2-Linux-x86_64.rpm

The example file is attached. It does not handle error case very nicely
and should probable put all logs in files instead of var.

In my case the "autoinstall" file is building an RPM and in my case I don't
want the 3) to 5) steps (default configure option should be enough).

May be a GUI would help to chose some parameters of the "autoinstall script"
version, CPack generator etc... but I don't think it must be the current
"cmake-gui".

> We've talked about a "build" button in the cmake-gui before, but if errors
> occur, you have to go elsewhere to edit code anyhow.
> If we have a build button, we have to:
> - make sure we handle voluminous output from the build tools
> - provide a way to interrupt a build in progress when the observer can't
> wait any longer...
> It shouldn't be hard, but it's not entirely trivial either. Deliciousness
> never is.

My opinion is that "automagicall one big button  (or small script) makes it all"
shouldn't handle error case at all.

Average user won't go and inspect why it fails.
He would probably just tell the project releaser that he/she did a poor job
and wait for him/her to fix that :-)

> What do others think? Is this a thing you've always wanted, or something
> you've never even wished for...?

One-line install command (or one button)
would be great but I think that if for any reason the automagic process
fails don't try to help the user with that but just point out the error file.

If it's a "power user" he will go back to current cmake UI.
If it's an average user he may file the error file back to the project releaser.

-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
# Simple cmake script which may be used to autoinstall 
# cmake from  automatically downloaded source
#
#   cd tmp/
#   cmake -P CMake-autoinstall.cmake
# you should end up with a
#   tmp/cmake-x.y.z source tree
#   tmp/cmake-x.y.z-build build tree
# configure and compiled tree, using the tarball found on Kitware. 

cmake_minimum_required(VERSION 2.6)
set(CMAKE_VERSION "2.8.2")
set(CMAKE_FILE_PREFIX "cmake-${CMAKE_VERSION}")
set(CMAKE_REMOTE_PREFIX "http://www.cmake.org/files/v2.8/";)
set(CMAKE_FILE_SUFFIX ".tar.gz")
set(CPACK_GEN "RPM")

set(LOCAL_FILE "./${CMAKE_FILE_PREFIX}${CMAKE_FILE_SUFFIX}")
set(REMOTE_FILE "${CMAKE_REMOTE_PREFIX}${CMAKE_FILE_PREFIX}${CMAKE_FILE_SUFFIX}")

message(STATUS "Trying to autoinstall CMake version ${VERSION} using ${REMOTE_FILE} file...")

message(STATUS "Downloading...")
if (EXISTS ${LOCAL_FILE})
   message(STATUS "Already there: nothing to do")
else (EXISTS ${LOCAL_FILE})
   message(STATUS "Not there, trying to download...")
   file(DOWNLOAD ${REMOTE_FILE} ${LOCAL_FILE}
TIMEOUT 600
STATUS DL_STATUS
LOG DL_LOG)  
   list(GET DL_STATUS 0 DL_NOK)
   if ("${DL_LOG}" MATCHES "404 Not Found")
  set(DL_NOK 1)
   endif ("${DL_LOG}" MATCHES "404 Not Found")
   if (DL_NOK)
  # we shall remove the file because it is created
  # with an inappropriate content
  file(REMOVE ${LOCAL_FILE})
  message(SEND_ERROR "Download failed: ${DL_LOG}")   
   else (DL_NOK)
  message(STATUS "Download successful.")
   endif (DL_NOK)  
endif (EXISTS ${LOCAL_FILE})

message(STATUS "Unarchiving the file")
execute_process(COMMAND ${CMAKE_COMMAND} -E tar zxvf ${LOCAL_FILE}
RESULT_VARIABLE UNTAR_RES
OUTPUT_VARIABLE UNTAR_OUT
ERROR_VARIABLE UNTAR_ERR
) 
message(STATUS "CMake version ${CMAKE_VERSION} has been unarchived in ${CMAKE_CURRENT_SOURCE_DIR}/${CMAKE_FILE_PREFIX}.") 

message(STATUS "Configuring with CMake...")
file(MAKE_DIRECTORY ${CMAKE_FILE_PREFIX}-build)
execute_process(COMMAND ${CMAKE_COMMAND} ../${CMAKE_FILE_PREFIX}
WORKING_DIRECTORY ${CMAKE_FILE_PREFIX}-build  
RESULT

Re: [CMake] Success using CPACK_RPM_POST_INSTALL_SCRIPT_FILE

2010-09-01 Thread Eric Noulard
2010/9/1 Yvan BARTHÉLEMY :
> Hi,
>
> Since I had some difficulties to use
> CPACK_RPM_POST_INSTALL_SCRIPT_FILE, i would like to share the failing
> steps I tried and their solution.
>
> First I tried to setup a project containing only one script to be
> included as a post-install script into a rpm archive.
>
> The folder archive is like this
>
> /test.sh : The script to be included as post-install script
> /CMakeLists.txt : A minimal CMakeLists that enlighten the problem
> cmake_minimum_required(VERSION 2.8)
>
> SET(CPACK_PACKAGE_NAME test)
> SET(CPACK_PACKAGE_VERSION 1.0)
>
> LIST(APPEND CPACK_GENERATOR RPM)
>
> SET(CPACK_RPM_POST_INSTALL_SCRIPT_FILE "test.sh")
>
> INCLUDE(CPack)
>
> The solution is simple, I just needed to change the line:
> SET(CPACK_RPM_POST_INSTALL_SCRIPT_FILE "test.sh")
>
> to:
> SET(CPACK_RPM_POST_INSTALL_SCRIPT_FILE "${CMAKE_CURRENT_SOURCE_DIR}/test.sh")
>
> This is needed because CPackRPM needs the absolute path of the file.
> CPack does not know that test.sh is relative to source tree.

Thank you Yvan to contribute to RPM documented usage and feedback.

I shall add that we could add more sophistication into CPackRPM to make
it "search" for test.sh at different places:
CMAKE_BINARY_DIR
CMAKE_SOURCE_DIR
etc ...
but currently it doesn't seem to be worth effort since specifying
absolute path is enough.


-- 
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] makefile to CMakeLists.txt, possible?

2010-09-01 Thread Eric Noulard
2010/9/2 Chiheng Xu :
> On Fri, Aug 20, 2010 at 1:11 AM,  <"\"Roman Wüger\"
> "@mac.com> wrote:
>> CMake is a Makefile-Generator an nothing else
>>
>> Why would you write the Makefiles by yourself?
>>
>
> Perhaps some people don't like the time consuming invocation of CMake.
>
> Maybe CMake can generate relocatable Makefiles only containing
> relative paths for several major platforms,  and developers "cache"
> the generated relocatable Makefiles in version control systems.  Then
> builders don't need to invoke CMake.

If you dig the ML you'll find several [very] good reasons why
it is not as easy as it seems for CMake to generate a set of
"relocatable" build files which does not need CMake anymore.
(currenlty generated Makefile (or other project files) may invoke CMake)

Trying to do that is not only difficult but will limit current CMake usability,
i.e. a lot of thing may happen "at cmake time" but you may want to
"invoke directly or indirectly cmake at build time too".

I'm not saying it wouldn't be theoretically possible nor practically useful
but that wasn't built in CMake design and now it seems difficult to do
with "not so much foreseen benefits".

As a side note, in the past, I did have to maintain a set of "portable
makefile" system
for 5 to 10 different platforms. After a while it was decided that we
should enforce
GNU make on all of them otherwise maintenance would be too time consuming.

After that I did use autotools for 3-4 years, then after 6+years of CMake usage
my point of view is that it's far easier to teach some of your
developper/builder how
to "basically" use CMake, than trying to maintain a portable build
system for all of them
using makefiles and/or autotools. Autotools may be OK if you do not
support windows platform.

I save a **lot of time** going from bare makefiles, to autotools and then CMake.

For those "bare [but respectable] builders" that do not want to touch CMakery
I usually try to craft some automated script like the one proposed here:
http://www.cmake.org/pipermail/cmake/2010-August/039270.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] Always compile source file in debug

2010-09-03 Thread Eric Noulard
2010/9/3 Belcourt, Kenneth :
> Hi,
>
> Apologies if this has been answered before.  In an effort to ensure
> cross-platform consistent results, I need to force some (C++ and Fortran)
> source files to always be built debug.  Is there any easy syntax to do this?
>
> I build our libraries like this.
>
> SET(SRCS
>  ${EXEC_DIR}/AfterStep.f90
>  ${EXEC_DIR}/ArgCF_Connect.f90
>  ${EXEC_DIR}/ArgCF_Solve.f90
>  ...
> )
>
> ADD_LIBRARY(exec ${SRCS})

You may set some specific flags on specific sources using something like

set_source_files_properties(file1.f90 file2.f90
  PROPERTIES
COMPILE_FLAGS ${CMAKE_FORTRAN_FLAGS_DEBUG})

but as far as I understand this does not replace default compile flags but add
extra flags for those particular source files...

Now if your "to be compiled with debug options" files may be contained in
separate libraries, may be you can create a sub-project which contains those
and enforce thsi subproject to be "CMAKE_BUILD_TYPE=Debug".


Curious to know, Why do you want to "some files" files to always be built debug
in the first place?

-- 
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] changing the cmake color scheme

2010-09-04 Thread Eric Noulard
2010/9/4 Abe Bachrach :
> Hi there,
> is there a way to change the color scheme that cmake uses while building??
> I would rather not have the message for linking be red, since this
> immediately makes me think there was an error.
> thanks,

Currently I don't think changing color is possible, because
they are chosen in source code

(see:cmLocalUnixMakefileGenerator3::AppendEcho
 in cmLocalUnixMakefileGenerator3.cxx)

The color is set depending on category:
  case EchoNormal:
break;
  case EchoDepend:
color_name = "--magenta --bold ";
break;
  case EchoBuild:
color_name = "--green ";
break;
  case EchoLink:
color_name = "--red --bold ";
break;
  case EchoGenerate:
color_name = "--blue --bold ";
break;
  case EchoGlobal:
color_name = "--cyan ";
break;

customized colorset should be failry easy to implement but you would
need to patch.


-- 
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] Simclist library produces simclist.c.o, simclist.c.i, simclist.c.s ...

2010-09-17 Thread Eric Noulard
2010/9/17 SC :
> David, Michael,
>
> Thank you for your help. [David, sorry for this double mailing to you]
>
>> > No, this is intentional, I suspect to avoid conflicts. There are people
>> > doing stuff like
>> > add_library(foo foo.c foo.cpp foo.f)
>> > Why is this a problem for you?
> Right, I understand the point of view of the CMake implementation. My problem 
> is that my project statically links
> the .o object file, hence the linker looks explicitly for simclist.o, and 
> since the file doesn't exist anymore, the
> link fails. I understand compiling foo.c and foo.cpp will both generate 
> foo.o, which obviously will conflict. But
> who does this ? This is weird isn't it ? It looks like walking on one's foot 
> to me !
>
> Of course I could alter my project's Makefile so that to reflect to 
> simclist.o -> simclist.c.o change. Doing this
> also means that eventually, in a few years, I might come through the same 
> kind of issue if Cmake generates not
> simclist.c.o but simclist.c.X.o or even simclist.o : I'd need to change my 
> project's makefile again so that I link
> with simclist.c.X.o or simclist.o.

Why are you talking about Makefile?
Common usage of CMake is to avoid writing any Makefile?

With CMake you write CMakeLists.txt and CMake generates the makefiles for you.

Concerning your static link you could build a static lib.


> I'd expect a way to force output file name. What's your opinion ? If you were 
> me, would you go into changing my
> project Makefile ?

Like I said you shouldn't be writing a "Makefile" unless you are
speacking about CMakeLists.txt.

>> Michael's exactly right. We consider the name and location of the object
>> files to be an implementation detail of CMake (and it's different on
>> different systems with different compilers) -- you cannot rely on those
>> details being exactly the same from version to version of CMake. Especially
>> not versions that are spaced *years* apart from each other.
> I understand. Nevertheless Cmake users need to know the name of the files 
> generated when building with the CMake
> generated file. IMHO, changing output file names from a Cmake to a revision 
> of Cmake can just break build chain.
> Risking this to avoid conflicting sounds odd to me.
>
> Well I got the point, I suspect I'll change my static link to simclist.c.o. 
> Guess it's the best thing to do, right ?

The best thing to do would be to build a static lib
ADD_LIBRARY(simclist STATIC simclist.c)
then to link to your static lib?

Why would you build a shared lib to link statically aftwerwards?

-- 
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] CMake error while run ./configure in Fedora

2010-09-20 Thread Eric Noulard
2010/9/20 Andi Purwito :
> Hello masters, please help me to fix this error.
> I couldn't compile gammu source on my Fedora 13 when running ./configure.

Then it looks like you'd better ask you question to Gammu developers and
not CMake.

But continue...

> Here is the error messages:
>
> CMake Error: CMake was unable to find a build program corresponding to "Unix
> Makefiles". CMAKE_MAKE_PROGRAM is not set. You probably need to select a
> different build tool.

This is explicit.
You should install "make"
something like

yum install make

should work.


> CMake Error: Error required internal CMake variable not set, cmake may be
> not be built correctly.
> Missing variable is:
> CMAKE_C_COMPILER_ENV_VAR
> CMake Error: Error required internal CMake variable not set, cmake may be
> not be built correctly.
> Missing variable is:
> CMAKE_C_COMPILER
> CMake Error: Could not find cmake module
> file:/home/smsgw/gammu/gammu-1.28.0/build-configure/CMakeFiles/CMakeCCompiler.cmake
> CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
> -- Configuring incomplete, errors occurred!
> To make sure what i'm doing, i was install cmake from fedora repository
> directly using "yum install cmake" and completed. And then to make sure
> again, i was update my gcc using "yum update gcc". But there was still
> errors during running ./configure. Finally, i decided to update all needed
> inside my fedora using "yum update" to make sure again. But, i got the same
> errors.
> :-) ???
>
> What's next i have to do to fix this error?

yum install make

but like I said if you have further trouble with gammu compile,
please ask Gammu developers 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] best practice way of copying libraries to an install package

2010-09-22 Thread Eric Noulard
2010/9/23 edA-qa mort-ora-y :
> On 09/23/2010 12:12 AM, Ryan Pavlik wrote:
>>> If anybody has a good resource, or can recommend some best practices,
>>> that would be great.
>> Use CMake and CPack?  See the wiki, and elsewhere on the internet.
>
> Yes, I am of course using CMake. My question is more along of the lines
> of how to best achieve the requirements of packaging. The "install"
> command on its own is pretty weak and locating and copying files
> requires all sorts of additional work (at least when it comes to
> finding/copying libraries, data files are fine).
>
> So I was wondering if there are some good, easy, or common ways to
> achieve packaging library dependencies.

Some CMake tries to help for that task.

InstallRequiredSystemLibraries.cmake  --> Windows only
GetPrerequisite.cmake
BundleUtilities.cmake

I think BundleUtilities try to achieve what you want, as far as I know
it was designed for MacOS but has been updated to work on
Linux and Windows as well.

GetPrerequisite is a basic helper which helps you find prerequisite
for an executable or library.

If you dig the mailing list about it you should find more valuable informations
about those.


-- 
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] Visual Studio project error

2010-09-23 Thread Eric Noulard
2010/9/23 J Decker :
> using 2.8.3-rc1 I decided to throw the project against visual studio
> and see what I got.
>
> clicking on the install target

I am responsible for this regression :-(

The issue is known, see those thread;
http://www.cmake.org/pipermail/cmake/2010-September/039668.html
http://www.cmake.org/pipermail/cmake-developers/2010-September/000561.html

A fix has been checked in 'git next' yesterday.
Should be in next RC.

Thank you for reporting the issue.

Eric

> -- Build started: Project: INSTALL
> (CMakePredefinedTargets\INSTALL), Configuration: Debug Win32 --
> 3>  CMake Warning (dev) at cmake_install.cmake:5 (SET):
> 3>    Syntax error in cmake code at
> 3>
> 3>      M:/build/vs10/sack/cmake_install.cmake:5
> 3>
> 3>    when parsing string
> 3>
> 3>      M:\build\vs10_sack_debug
> 3>
> 3>    Invalid escape sequence \b
> 3>
> 3>    Policy CMP0010 is not set: Bad variable reference syntax is an error.  
> Run
> 3>    "cmake --help-policy CMP0010" for policy details.  Use the cmake_policy
> 3>    command to set the policy and suppress this warning.
> 3>  This warning is for project developers.  Use -Wno-dev to suppress it.
> 3>
>
> Fixed by modifying CMAKE_INSTALL_PREFIX to M:/build/vs10_sack_debug
> from M:\build\vs10_sack_debug
> ___
> 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
>



-- 
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] Visual Studio project error

2010-09-23 Thread Eric Noulard
2010/9/23 Bill Hoffman :
> On 9/23/2010 3:13 AM, Eric Noulard wrote:
>>
>> 2010/9/23 J Decker:
>>>
>>> using 2.8.3-rc1 I decided to throw the project against visual studio
>>> and see what I got.
>>>
>>> clicking on the install target
>>
>> I am responsible for this regression :-(
>
> Not so sure it is the same thing...
>
> Note, the whole path is wrong:  M:\build\vs10_sack_debug
>
> Your bug only did the last \.

You are perfectly right.

The fact is I didn't supposed that this wasn't working before...thus
my too fast conclusion.

Either way, both cases need testing, may be the last one needs a
separate bug/feature request report.


-- 
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] ccmake and cmake

2010-09-23 Thread Eric Noulard
2010/9/24 Michael Wild :
>
> Oh, wow, hardy is REALLY, *REALLY* old. It still contains only cmake-2.4.7 
> which was released more than 3 years ago!
>
> I would recommend downloading a pre-built binary. It is self-contained and 
> you can just drop it anywhere you want (e.g. somewhere in your home 
> directory) and simply update your PATH variable. You can get the latest 
> source and binary tar-balls from here: 
> http://cmake.org/cmake/resources/software.html

Once you have at least CMake 2.6 you can try to rebuild a .deb using
CMake itself
using the attached CMake script:

mkdir tmp
cd tmp
cmake -P  /path/to/CMake-autoinstall-DEB.cmake

This makes a "default" cmake build which contains cmake and ccmake
(but not cmake-gui).

In the end you should end up with a deb package ready to be installed
using dpkg.
If you install the new deb you will remove the cmake version shipped
with your distro,
if you want to keep several cmake version installed you'd better
install binary TGZ archive
somewhere and may be select default CMake using update-alternatives.

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


CMake-autoinstall-DEB.cmake
Description: Binary data
___
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] Manual page generation

2010-09-24 Thread Eric Noulard
2010/9/24 Laszlo Papp :
> This did not work either :((( :

Could you gives us more informations.

Which version of CMake do you use, on which platform?

How do you process your CMakeLists.txt (command line, GUI, etc...)

What is the output of CMake when processing the file ?

Is this CMakeLists.txt part of a bigger project ?
If yes did you add appropriate "add_subdirectory" in the parent dir ?

etc...

-- 
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] How to list user-definable CMake variables

2010-09-28 Thread Eric Noulard
2010/9/28 Marcel Loose :
>
> On 28. Sep, 2010, at 9:33 , Marcel Loose wrote:
>
>> > Hi all,
>> >
>> > I was wondering how I could generate a list of user-definable CMake
>> > variables. This list, with a brief help per variable, would be
> *very*
>> > useful for the end-user. It's a bit like the well-known "configure
>> > --help" which gives you a overview of all variables that can be set.
>> >
>> > Best regards,
>> > Marcel Loose.
>>
>> Is "cmake -LAH" what you want?
>>
>> Michael
>
> Hi Michael,
>
> Well this is sort of what I was looking for, though I was hoping that it
> would be possible to list any useful variable *before* running CMake.

Before running cmake... I don't know but keep reading.

> Is there some kind of hook, e.g. 'cmake --custom-help', that can be used
> to display project-specific help. The help text should be provided by
> the developer, of course.

You may do the following:

Write an "HelpMe.cmake" file which contains CMake comments
just like plain CMake do (see e.g. CPackRPM.cmake which contains many
variable descriptions)

then add the following custom target to your project:
add_custom_target(HelpMe
  COMMAND  ${CMAKE_COMMAND}
-DCMAKE_MODULE_PATH=${CMAKE_CURRENT_SOURCE_DIR} --help-module HelpMe
  COMMENT "Display User defined help")

this will use the "--help-module" option of cmake to display your custom help.

user can call the target

make HelpMe

and the help will be display.

You may want to call your target "help" but it would conflict/override
the cmake builtin "help" target
(at least for makefile generator) which display the list of available target.

This work AFTER cmake has been run. It could be run before as well using:

cmake -DCMAKE_MODULE_PATH=/path/to/source --help-module HelpMe

but this is awkward :-(

-- 
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] How to list user-definable CMake variables

2010-09-28 Thread Eric Noulard
2010/9/28 Marcel Loose :
>>
>> You may want to call your target "help" but it would conflict/override
>> the cmake builtin "help" target
>> (at least for makefile generator) which display the list of available
> target.
>>
>> This work AFTER cmake has been run. It could be run before as well
> using:
>>
>> cmake -DCMAKE_MODULE_PATH=/path/to/source --help-module HelpMe
>>
>> but this is awkward :-(
>>
> Thanks Erk,
>
> I'll give it a thought. Your solution uses some nice CMake features, but
> I find it a bit awkward. It suffers from separation of code and
> documentation, though. That's always risky, since the two are likely to
> diverge.

It is a little bit, but you can put in this "custom cmake file"
(you may rename it to "CustomizableOptions.cmake")
any CMake *code* you want including the definition of OPTION or vars
(using SET) etc...

then in you CMakeLists.txt you can

include(CustomizableOptions.cmake)

and the "header" of the file contains the useful doc. for the
concerned option/vars.

then the code and it's doc stay together.




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


[CMake] Howto compile static executable?

2010-09-28 Thread Eric Noulard
Hi All,

I have project which (cross-)compile some simple C applications
with some bare CMake statement like this:

add_executable(myapp myapp.c)

no target_link_libraries, no dep,  etc...

I want to build fully static executable (even for libc etc...)
Currently I do:

set_target_properties(myapp PROPERTIES LINK_FLAGS_DEBUG "-static")

is there a better and portable way to require "static" executable?

I am aware of the BUILD_SHARED_LIBS var for globally controlling
static vs dynamic libs but how can I do for executable?

-- 
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] file COPY/INSTALL doesn't overwrite existing files?

2010-09-30 Thread Eric Noulard
2010/9/30 Guillaume Duhamel :
> Hi,
> I'm trying to use "file(COPY ..." during the build of one of my project.

"file(COPY ..." is a **CMake-time** command, i.e. it will be processed
when CMake runs
and not when building (unless make is triggering a cmake run)
If you want **Build-time** command you'll have to use

add_custom_command/add_custom_target

> The documentation says that files get overwritten according to their
> timestamps, but it seems they just never get overwritten.
> For instance, with this CMakeLists :
> ===
> project(test)
> cmake_minimum_required(VERSION 2.8)
> file(INSTALL dir DESTINATION ${CMAKE_CURRENT_BINARY_DIR})
> file(INSTALL bar.txt DESTINATION ${test_BINARY_DIR}/dir)
> ===
> and those steps :
> $ mkdir build && cd build && cmake .. && make
> $ echo "something new" >> ../bar.txt
> $ make
> bar.txt doesn't get overwritten after the second make.
> Is there anything I'm doing wrong or do I have to detect existing files
> and remove them before the copy?

try

add_custom_command(
  OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/dir ${CMAKE_CURRENT_BINARY_DIR}/dir/bar.txt
  COMMAND ${CMAKE_COMMAND} -E copy_directory
${CMAKE_CURRENT_SOURCE_DIR}/dir ${CMAKE_CURRENT_BINARY_DIR}/dir
  COMMAND ${CMAKE_COMMAND} -E copy_if_different
${CMAKE_CURRENT_SOURCE_DIR}/bar.txt
${CMAKE_CURRENT_BINARY_DIR}/dir/bar.txt
  )

or something similar.

-- 
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] CMake/Buildbot xplat upload?

2010-10-01 Thread Eric Noulard
2010/10/1  :
>
> Hi list,
>
> I Googled for this but didn't find anything.
>
> CMake is integrating well with Buildbot to make a sort of poor-man's
> build farm. The one thing I can't seem to work out is a crossplatform
> way to upload CPack-built packages (Windows and Linux) to a web server
> (Ubuntu).

that's true you have file(DOWNLOAD ...) (which internally uses libcurl)
so it should be fairly easy to add file(UPLOAD ...) but currently
AFAIK this does not exists...
may be worth a feature request.

> The target web server supports SSH, SCP, DAV and possibly NFS.
> Any ideas? Or should I be asking Buildbot's mailing list?

I don't know or use buildbot but it appears to be written in python so may
I guess python may be required when using build bot.
May be using some 100% python SSH lib (in order to be cross platform)
like paramiko
(http://www.lag.net/paramiko/) is doable in order to transfer your
files using scp.

You may call your python scp script from CMake using execute_process
after a find_package(PythonInterp).

-- 
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] rpmbuild breaks if HOME is wrong

2010-10-04 Thread Eric Noulard
2010/10/4  :
>
> Hi list,
>
> I notice rpmbuild tries to use the HOME directory as a base for its
> files. This won't work if HOME is set wrongly (eg. by "sudo -u other
> bash"), as in my case.

If you are speaking about CPackRPM generator then NO it shouldn't use HOME dir.
If it is the case then may be you have a some custom .rpmrc somewhere?

If not could you gives us more informations:
  - Which version of CMake
  - Which Linux system (Mandriva, RedHat, OpenSuSE, Fedora...) with version

> Is it possible to stop it doing this and make it use the CPack build
> hierarchy?

Like I said that should already be the case.
Could you try to run the following command in your build directory:

cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -G RPM

and send me the output.



-- 
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] rpmbuild breaks if HOME is wrong

2010-10-04 Thread Eric Noulard
2010/10/4  :
>
> On Mon, 4 Oct 2010 18:19:20 +0200
> Eric Noulard  wrote:
>
>> If you are speaking about CPackRPM generator then NO it shouldn't use
>> HOME dir. If it is the case then may be you have a some custom .rpmrc
>> somewhere?
>
> Oh. I guessed it was the rpmbuild default. Maybe I do have a .rpmrc
> somewhere. (Can't think why I would but I'll check anyway.)

May be it's the rpmbuild default (I didn't checked) but CPackRPM
is telling rpmbuild explicitely the BUILDROOT it should use
in 2 ways (some version of rpmbuild did not honor one of them):

using the --buildroot argument of rpmbuild command,

and
we re-specify this inside the generated spec file using:
BuildRoot:

field.

May be you can check in the generated spec file whether
if this field has an appropriate value.

>> If not could you gives us more informations:
>>   - Which version of CMake
>>   - Which Linux system (Mandriva, RedHat, OpenSuSE, Fedora...) with
>> version
>
> fat...@nikko:/var/lib/buildbot$ cmake --version
> cmake version 2.8.1
> fat...@nikko:/var/lib/buildbot$ lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description:    Ubuntu 10.04.1 LTS
> Release:        10.04
> Codename:       lucid
> fat...@nikko:/var/lib/buildbot$ uname -a
> Linux nikko 2.6.32-24-generic-pae #43-Ubuntu SMP Thu Sep 16 15:30:27 UTC
> 2010 i686 GNU/Linux
> fat...@nikko:/var/lib/buildbot$
> I discovered the "wrong HOME" problem in rpmbuild.err and tested with
> a corrected HOME variable. It worked, so the problem at least involves
> the HOME variable, somehow.

OK currently I cannot reproduce the problem.

Could you explain me why the buildbot would have an invalid HOME
do you use

a) "su "
b) or "su - "
c)  or "sudo"
d)  crontab  -u buildbot cron.file
e) other way?

to buildbot from another user?

If yes from which user to su from using which method (a,b,c,d,e)?

If I do

1) login with user 1
2) su to user2
3) go to whatever build dir belonging to user2
4) calling cpack -G RPM

from your point of view should I see the problem or do you have some
other steps I miss ?

> error: failed to create directory %{_topdir}: /home/fatman/rpmbuild:
> Permission denied

May be you can send me the whole rpmbuild.err and rpmbuild.out files?

>> Could you try to run the following command in your build directory:
>>
>> cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -G RPM
>>
>> and send me the output.
>
> Note the different user. This is why the HOME variable is wrong.

Why would it be wrong?
su - 
or
su 

should setup HOME properly (at least it is the case on my systems
Debian Squeeze and Ubuntu 10.04)

> build...@nikko:/var/lib/buildbot/Reu2/slave/bin/nikko/build/cmake$
> cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -G RPM CPack: Create package using
> RPM CPack: Install projects CPack: - Run preinstall target for: Reu2
> CPack: - Install project: Reu2
> CPack: Compress package
> CPackRPM:Debug: rpmbuild version is <4.7.2>
> CPackRPM:Debug: CPACK_TOPLEVEL_DIRECTORY
> =
> /var/lib/buildbot/Reu2/slave/bin/nikko/build/cmake/_CPack_Packages/Linux/RPM

is the previous directory belonging to user buildbot ?

[SNIP]

> /var/lib/buildbot/Reu2/slave/bin/nikko/build/cmake/_CPack_Packages/Linux/RPM/Reu2-0.1.1-Linux.rpm
> to /var/lib/buildbot/Reu2/slave/bin/nikko/build/cmake/Reu2-0.1.1-Linux.rpm
> CPack Error: Error when generating package: Reu2
> build...@nikko:/var/lib/buildbot$
>
> By the way, I am also building a DEB and TGZ package. They both
> complete successfully.

Yes but even if rpm building is enabled on Debian based host it's possible
that rpmbuild is not "working as expected" on such host.

By any chance do you have any other buildbot machine which would be RPM based
which exhibits the same trouble?

-- 
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] rpmbuild breaks if HOME is wrong

2010-10-05 Thread Eric Noulard
2010/10/5  :
>
> On Mon, 4 Oct 2010 20:45:21 +0200
> Eric Noulard  wrote:
>
>> May be you can check in the generated spec file whether
>> if this field has an appropriate value.
>
> Apologies/length.

[SNIP]

Ok now I see the precise scheme.
I'll try to reproduce that.

Unfortunately I will be off network for a while so could you be kind
enough to open a bug tracker entry
http://public.kitware.com/Bug/my_view_page.php
and add a reference to this thread of discussion
http://www.cmake.org/pipermail/cmake/2010-October/040011.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] Adding a library to link in during TRY_RUN with Windows/nmake?

2010-10-12 Thread Eric Noulard
2010/10/12 Clifford Yapp :
> I'm trying to compile some C code using TRY_RUN that uses gethostname,
> but in order for this code to succeed on Windows it needs "/link
> ws2_32.lib" added to the compile line.  I have tried putting this
> string into the ARGS variable of TRY_RUN and a couple of CMake
> variables, but the compile still fails and I can't see any indications
> the extra link argument is being passed... am I doing something wrong?

May be you could the higher level "CheckCSourceRuns" modules
which has explicit var for what you want:

$ cmake --help-module CheckCSourceRuns
cmake version 2.8.2
  CheckCSourceRuns
   Check if the given C source code compiles and runs.

   CHECK_C_SOURCE_RUNS( )

- source code to try to compile
 - variable to store the result
(1 for success, empty for failure)

   The following variables may be set before calling this macro to modify
   the way the check is run:

 CMAKE_REQUIRED_FLAGS = string of compile command line flags
 CMAKE_REQUIRED_DEFINITIONS = list of macros to define (-DFOO=bar)
 CMAKE_REQUIRED_INCLUDES = list of include directories
 CMAKE_REQUIRED_LIBRARIES = list of libraries to link



   Defined in: /usr/share/cmake-2.8/Modules/CheckCSourceRuns.cmake


>  Alternately, does anybody know of a pre-existing cross-platform way
> to get the hostname from CMake?

Don't know.

I think that on many Unix "hostname" command exists.
It looks like it exists on some Windows flavor too:
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/hostname.mspx

so may be an "execute_process" call with hostname command is portable?

-- 
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] How to rename the resulting Makefile.

2010-10-12 Thread Eric Noulard
2010/10/12 william.croc...@analog.com :
> Hello:
>
> I'm a newbie cmake user and would like to rename the makefile
> produced by running cmake.

As far as I know there is none.
But... may be you could do a out-of-source build
http://www.cmake.org/Wiki/CMake_FAQ#Out-of-source_build_trees
and avoid this problem alltogether?

> This is useful because:
>
> 1 - It provides a convenient way to slowly transition form
>    existing makefiles to the use of cmake.

Out-of-source solves this.

> 2 - I fill my makefiles full of all sorts of convenient
>    targets like the following and I do not want to have
>    to figure out how to do them in cmake.
>
>       grep :
>           @-for c in ${COMPONENTS} ; do \
>                echo " grep:" $$c; \
>                ( cd ./$$c; grep -i xyz *.h *.c *.cc ) ; \
>             done

Sooner or later you may have to do it, and it may not be as
difficult as you think.

>
> This is possible with Qt/qmake:
>    MAKEFILE = xyz.make
>
> Obviously I could issue an OS command to rename the
> makefile, but that is an extra step which would be forgotten,
> varies from OS to OS and would clobber my real makefile
> which is named Makefile.

May be you can rename your old "Makefile" as "Makefile.manual" ?

-- 
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] How to rename the resulting Makefile.

2010-10-12 Thread Eric Noulard
2010/10/12 william.croc...@analog.com :
>
>>>
>>> [ elided ]
>>>
>>> So, is there a command I can place in my CMakeLists.txt files
>>> which will cause them to produce a file named xyz.make (let's say)
>>> instead of Makefile.
>>>
>>> Thanks in advance.
>>
>> Use out of source builds, and there should be no-conflict.  There is no
>> way to rename the makefiles.
>>
>> mkdir build
>> cd build.
>> cmake ../path/to/source
>> make
>>
>
> Okay. I see that OOS builds can create Makefiles without clobbering
> my existing Makefile, but then I do not have convenient access to my
> Makefiles
> and the convenience targets they contain from the OOS dir.

Yes you do:

add_custom_target(save
 COMMAND ${CMAKE_MAKE_PROGRAM} save
 WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
 COMMENT "Home brewed make save target")


but I wouldn't do that.

> I still think Qt/qmake was right in providing the ability to change
> the name of the Makefile. Before I discovered that, I could not use
> the qmake system.

I agree that it would be a good feature to be able to change the name
of generated
makefiles, but if you dig the ML you'll see that **after discussion**
there is not
so many **useful** cases to do that.

> Below is typical of what my Makefile contains:
> Convenience targets (all in one place) and a call to the makefile
> created by qmake (myapp.make). In this way qmake does not have to solve
> the whole problem, just contribute a part of the solution.

But you home-brewed Makefile is not cross-platform which is one of the
primary target for using CMake :-]

Moreover you have to described you lib and executable target names
in two places (CMakeLists.txt and home made Makefile) which
opens a window for inconsistency.

> --
>
> myapp : always
>        make -f myapp.make
>
> save : always
>        mkdir -p save_dir
>        /bin/cp -pr *.h *.cc *.lyx *.xml *.xsl *.txt *.css Makefile save_dir

You can use add_custom_target and basic CMake scripting for doing just the same.
Look at

file( ...) commands

-- 
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] How to rename the resulting Makefile.

2010-10-12 Thread Eric Noulard
2010/10/12 william.croc...@analog.com :
>
> I will use cmake to build the app on my various platforms
> (Linux/Windows...).
> Most of my convenience targets are only used during development (Linux)
> so it is typically okay that they are not cross platform.

ACK.

>>
>> file( ...) commands
>>
>
> Yes I see.
> But if I had the ability to change the name of the Makefile I could
> start using cmake right now. If I have to rewrite my entire makefile
> the cmake way (all or nothing) it will take weeks.

How many "custom rules" do you have?
Week looks like a lot of time :-)

Nevertheless,
I think may be you did not fully read my answer (unless I'm wrong)
but you CAN call [part of] your home made makefile rules
** FROM THE SEPARATE CMAKE BUILD  **

if you add some extra CMake lines like the following:

add_custom_target(save
COMMAND ${CMAKE_MAKE_PROGRAM} save
WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
COMMENT "Home brewed make save target")

The previous line will create in the CMake generated makefile
a rule which when invoked will call your makefile rule
(same name) in the source tree.

Those lines may easily be generated with a small script.

> Anyway. I understand. We can leave it at that.
>
> Thanks for all the help.

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] CPACK "deb" package Problem

2010-10-14 Thread Eric Noulard
Hi Chang,

2010/10/14 Chang Yu Huang :
> Here is my CMakeLists.txt file, and when I use the "make" and "make install"
> command, I can successfully install all files into the file system.

You think you do but in fact you don't :-], but keep reading.

> However, when I use the "make package" command, there is no any file be
> packaged in "deb package", I would like to ask why, thanks a lot.


There is some "problem/weirdness" with your CMakeLists.txt

1)  EXECUTABLE_OUTPUT_PATH is not meant to "install" things
>
> SET(EXECUTABLE_OUTPUT_PATH /usr/bin)
[...]
> ADD_EXECUTABLE (my_project ${MY_PROJECT_SRCS})
[...]

So here you are putting your executable in "/usr/bin"
AT BUILD TIME and you have no INSTALL rule
for your "my_project" executable.

This is not usually the way it goes.
First of all note that with CMake you have several "times":

0) CMake time = when CMake is running
1) Build time= when the build tool is running (in your case "make")
2) Install time   = when install target is launched
3) CPack time  = when CPack is running
4) Package Install Time = when the package you build with CPack is installed

0) is essentially the configuration of your sources

1) is when all sort of things (including libraries and executable) are built
usually within the BUILD TREE

2) All INSTALL rules specified in CMakeLists.txt are processed.

3) When running CPack, cpack runs the step 2) using specific arguments
in order to install everything in a local sub-directory of the build tree
before packaging.

> INSTALL(FILES my_project.glade DESTINATION /usr/share/my_project)
> INSTALL(FILES my_project.png DESTINATION /usr/share/my_project)
> INSTALL(FILES my_project.desktop DESTINATION /usr/share/applications)

You use ABSOLUTE destination, this is known to be broken for many
CPack generator (including DEB, RPM and TGZ).
This should be fixed (for RPM and DEB) in the forthcoming 2.8.3 cmake release.

However, you should probably use relative destination:

INSTALL(FILES my_project.glade DESTINATION share/my_project)
INSTALL(FILES my_project.png DESTINATION share/my_project)
INSTALL(FILES my_project.desktop DESTINATION share/applications)

[...]

> TARGET_LINK_LIBRARIES(deva ${GTK2_LINK_FLAGS})

As already said you lack an install rule for your target;

INSTALL(TARGET deva bin)

In summary;

1) You should really not be using /usr/bin as EXECUTABLE_OUTPUT_PATH
EXECUTABLE_OUTPUT_PATH is is build time var not meant to replace
intall time procedure.

2) You'd better use relative install path
If you want to stick with absolute install
you may have to set(CPACK_SET_DESTDIR ON)

3) You should have 1 install rule for each target/file/directory you
want to install
The CPack package will only contains things for which there exists
an install rule.

-- 
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] Possible changes in CPackRPM.cmake in version 2.8.0

2010-10-14 Thread Eric Noulard
2010/10/14 Karl Krissian :
>  Hi,
>
> I made the following changes to the file
> /usr/share/cmake/Modules/CPackRPM.cmake to be able to use it for my
> software:
>
> diff /home/karl/amilab_trunk/CMAKE/CPackRPM.cmake
> /usr/share/cmake/Modules/CPackRPM.cmake
> 283,285c283
> <                 COMMAND sed {s/\\.//}
> <             COMMAND sed {s/$/\"/}
> <         COMMAND sed {s/^/\"/}
> ---
>>                COMMAND sed {s/\\.//}
> 369c367,369
> <     COMMAND "${RPMBUILD_EXECUTABLE}" -bb
>  --buildroot=${CPACK_RPM_DIRECTORY}/${CPACK_PACKAGE_FILE_NAME}/
> "${CPACK_RPM_BINARY_SPECFILE}"
> ---
>>     COMMAND "${RPMBUILD_EXECUTABLE}" -bb
>>             --buildroot
>> "${CPACK_RPM_DIRECTORY}/${CPACK_PACKAGE_FILE_NAME}"
>>             "${CPACK_RPM_BINARY_SPECFILE}"
>
> Basically, I replaced "--buildroot "${path}"" by "--buildroot=${path}" and I
> added quotes around the filenames to deal with spaces inside.
>
> I also removed the quotes around the buildroot directory since it was a
> source of error, but then the directory cannot include spaces anymore.

Which is bug report, which should be fixed in 2.8.3 :-]

Would you be able to give latest CMake 2.8.3/CPack rc a try?

I think it should fix your problems (while maintaining the support for
space in filename ... and many more things)

If not please file a bug report may be including a small example project which
exhibits the issue.

> P.S. : I used rpmbuild from RPM 4.8.1

Ok should work with 2.8.3.

If you have trouble with CPackRPM you can run it with debug output on like this:

cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -G RPM

and you will have trace of what CPackRPM is doing (including the
version of rpmbuild used).


-- 
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] Possible changes in CPackRPM.cmake in version 2.8.0

2010-10-15 Thread Eric Noulard
2010/10/15 Karl Krissian :
>
> OK,
>
> It worked with the nightly build of cmake.

Ok then that's fine.
Thank you for testing.

-- 
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] Bootstrap script generation?

2010-10-15 Thread Eric Noulard
2010/10/15 Clifford Yapp :
> CMake itself, when building from source, has a bootstrap script it
> uses to get going.  Can such scripts be generated by CMake for other
> project to enable building on machines without CMake?

Do you mean is CMake polymorphic and pretend it is autoconf ?

Just kidding :-]

No I don't think so, the only thing I can think of is either bootstrap CMake
itself and then go on with CMake or may be auto-install CMake with some
script getting appropriate binary version from Kitware and go on with ...

Note that CMake bootstrap script does not work on Windows, and one has
to rely on a previous CMake version to compile CMake on such platform.

-- 
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] Complete rebuild after svn update

2010-10-18 Thread Eric Noulard
2010/10/18 Alex Brooks :
> Hi,
>
> I have a problem where cmake decides to rebuild my entire source tree when an
> svn update pulls in a change to a CMakeLists.txt file.
>
> I have a fairly complicated build tree with a number of sub-libraries etc.
> The whole thing takes something like an hour to build, so it's a big chunk out
> of my day.
>
> I tried a few things to characterise the problem:
>  - If I locally touch CMakeLists.txt files, or even make non-trivial changes,
> cmake does the correct thing and just rebuilds what is necessary.
>  - If an svn update pulls in a changes to .h or .cpp files, cmake again does
> the correct thing.
>  - If an svn update pulls in even a trivial change (e.g. a change to a
> comment), cmake rebuilds every single source file.
>
> I've run out of ideas about how to characterise the problem better, does
> anyone have any ideas what the problem might be, or what to do next to track
> it down further?

May be svn is the culprit.

Did you have a look at the timestamp of the file/directory enclosing
(and up) the
changed CMakeLists.txt after the svn update?

May be a single change inside a directory change the timestamp
of a set of file?

Another option may be that this particular CMakeLists.txt is generating
(using configure_file) some file that is [indirectly] included by many other?

May be you can have look at the dependencies in
CMakeFiles/Makefile.cmake
-- 
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] How to choose different complier?

2010-10-18 Thread Eric Noulard
2010/10/18 董隆超 :
> Hi,everybody
>
> I am new to CMake and I have a question.
> I think CMake choose complier based on the file name.If it is ".cpp",CMake
> will use g++, if it is ".c",gcc will be used.Is it right?So to switch
> between g++ and gcc,I have to change the file name every time.I know this is
> very stupid,but I really do not know how to choose special complier by
> hand.If the file name is ended with ".c",I want to use g++ to compile it.So
> how to do?
> Thank you in advance.

set_source_files_properties(yourfile.c LANGUAGE CXX)

see:

cmake --help-command set_source_files_properties

-- 
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] Cmake Releases

2010-10-20 Thread Eric Noulard
2010/10/20 Mohammed Aziz Parande :
> Dear Developers,
>
> I am a graduate student from University of Maryland Baltimore County.
>
> I have a simple question pertaining to Cmake Development Cycle.
>
> Has Cmake gone under some refactoring efforts before any of its release? If
> yes could you please tell me which release was it.

I would say that you have all source code from release to release to compare
for that yourself?

More seriously I cannot tell myself but I would very interested to know WHY
you are asking such a question?

Let's say that between 2.6.4 and 2.8.0 there was some refactoring
(fictitious example) what you do yourself with such piece of information?

> Your response would be highly appreciated.

Yours as well :-]
-- 
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


[CMake] Creating Debian source packages with CMake

2010-10-20 Thread Eric Noulard
Retransmit on the ML.

-- Forwarded message --
From: Eric Noulard 
Date: 2010/10/20
Subject: Re: [CMake] Creating Debian source packages with CMake
To: Daniel Pfeifer 


2010/10/20 Daniel Pfeifer :
> Hi,
>
> CPack, the packaging system that ships with CMake, builds
> component-based installers for Mac OS X and Windows only. On Linux, the
> packages generated by CPack are single, monolithic units.

Yes that's true.
The main reason was the fact that there were some (several) technical issues
for creating component that had to be addressed first.

Forthcoming CMake 2.8.3 has many improvment regarding component based packaging.
An example of application is the fact that now any CPack archive generator
(ZIP, TGZ, TBZ2, etc...) are able to generate one archive per component.

see this thread on the ML:
http://www.cmake.org/pipermail/cmake/2010-August/038663.html

> I hacked a CMake script that creates a single deb-src package, uploads
> it to the Launchpad build service where it generates one deb package for
> each component.

 cool!! I'll have a look at this.

> Read more at: http://purplekarrot.net/blog/dputCMake.html
> Use the script at your own risk, and please provide feedback.

May be you can open a new feature request in the bug tracker
(http://public.kitware.com/Bug/my_view_page.php)
which reference your work.

That way we may collaborate to make this contribution into mainstream CMake.

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



-- 
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] Creating Debian source packages with CMake

2010-10-21 Thread Eric Noulard
2010/10/20 Daniel Pfeifer :
>> What would a 'debian/rules' file that used CPack look like?
>
> The `debian/rules` file that is generated by my script does currently
> not rely on CPack since CPack cannot generate more than one package.

In order to be sure I make myself clear.

CPack (2.8.3rcXX) **CAN** generate more than one package
see this bug if you want to know more about that issue:
http://public.kitware.com/Bug/view.php?id=10736

Now EACH CPack generator have to decide how to handle this.
Currently (2.8.3rcXX) the "multi-package" may be driven by the CPack
component definition
http://public.kitware.com/Bug/view.php?id=10130
for the CPack Archive Generator (ZIP, TZ, TGZ, etc...)

Support for DEB and RPM are wanted but the work needed for those
generators has not started YET.

I plan to begin with RPM:
http://public.kitware.com/Bug/view.php?id=7645
because I think I know how to do it
(I just have to find enough time to make through)

I would be glad to have some help to do it for DEB too.
I'll try my best to support and help anybody wanting to work on this,
Daniel may be?

Concerning pro- and cons- to use CPack for deb / rpm / whatever
packaging w.r.t. "official way" packager do the jobs there has been
several discussion on the ML, I suggest you searc the list
concerning this subject.

Basically as far as I remember many people like to be able to build
.deb or .rpm for their software in order to please their users.
Usually they don't want to learn how to do it
"the debian way" or "the Fedora way" or whatever because either:
1) they don't have time to do that
2) their software is not widespread enough to step in major distro
3) Official distro packager do already do that for them.

May be some time in the future CPack can mature enough and
become able to build .deb the "official debian way" or .rpm "the
official OpenSuSE way".
This is not the case today, I don't think it's a primary goal but that
does not mean it cannot be done.

-- 
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] CMake with CPack - unresolved libraries

2010-10-25 Thread Eric Noulard
2010/10/25 Marcin Czenko :
> Hello everybody.
>
> I need your help to solve the following problem.
>
> The installed version of CMake is:  2.8.0.
> The installed version of CPack is: 2.8.0.
> I am running on Ubuntu LTS 10.04.
>
> I have a CMake project. The output of the project is an executable. The
> executable depends on a number of shared
> libraries:
>
> =
>> ldd UserCockpit-Application

[...]
> =
>
> Now I am trying to use CPack with CMake to make a deb package. Everythig
> works perfectly except one thing. When I run ldd on the executable that is
> included in the package I get the following output:

[...]

You may try to use full RPATH:
http://www.cmake.org/Wiki/CMake_RPATH_handling

However I have 2 questions:

 1) Is your ldd test done AFTER installing the .deb ?

 2) Does the "not found" libraries belong to your CMake-handled project or
 to third party libraries?


-- 
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] cmake policy setting

2010-10-29 Thread Eric Noulard
2010/10/29 Marco Atzeri :
> As there is no example in the documentaion,
> could someone clarify me if the change of any policy
> that should require an additional
>
> cmake_policy(SET CMP NEW)
>
>
> could also be requested at cmake invocation with
> ---
> # -D :=: Create a cmake cache entry.
>
> When cmake is first run in an empty build tree, it creates a CMakeCache.txt 
> file and populates it with customizable settings for the project. This option 
> may be used to specify a setting that takes priority over the project's 
> default value. The option may be repeated for as many cache entries as 
> desired.
> ---

I do not think policy value reaches the CMake cache.

and I don't know a way to set up policy from command line.

I'll have to check the code but even if policy has the "SET" argument in it
it does not share properties with the CMake "set" command itself.

"set" and "cmake_policy" are 2 separate CMake commands.

the -D := command line argument may "replace"
"set" command in CMakeLists.txt but I am not aware of any command
line args that may be used to enforce policy.

Again I'll have to check the source code to be sure.

-- 
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] How to differ?

2010-10-29 Thread Eric Noulard
2010/10/29 Thomas Lehmann 
> Hi,
>
> I’m new to the cmake tool trying to find out how to apply
> this best to our system. Here’s a problem I would like
> to know how to do best:
>
>
>
> Assume following setup:
>
> -  /projects/libs/one
> -  /projects/libs/two
> -  /projects/apps/first
> -  /projects/apps/two
>
> Both application are using both libraries.
>
> Being in /tmp/obj ….

What does this mean "being in /tmp/obj" ?

> I have  some options to prepare a build:
>
> -  cmake /projects   (this means: intending to build all)
> -  cmake /projects/libs (this means: intending to  build all 
> libraries only)
> -  cmake /projects/apps (this means: intending to build all 
> applications)
> -  cmake /projects/apps/first (this means: intending to build app 
> “first” only)
> Now the question(s):
>
> -  Using “build all” is fine. I’m using “link_directories” for both 
> applications.
> But using the last two examples I fail with “cannot find –lone” (and two).
> How can I fix this?
>
> -  I know I could use “include_subdirectory” but then I fail with 
> first and third
> example. I will get a message like “another target with same name already 
> exists”.
> Both question are relating to same.

I think I don't get it.
What do you want to do?

1) Write a single CMake-enabled project with which you may build all
or part of the project

2) Write several separate CMake-enabled project which are inter-dependant?

I would personnally try 1) unless you have good reason not to do so.
The projects/CMakeLists.txt would be the main project
consisting in some
add_subdirectory(libs/)
add_subdirectory(apps//)
then for each lib there will be some
projects/libs//CMakeLists.txt consisting in
add_library( ) command
and for each app there will be some
projects/apps//CMakeLists.txt which contains
add_executable( )
target_link_library( )
include_directories(${CMAKE_SOURCE_DIR}/libs/)

from this structure you should be able to build part or all of the target
just by calling the appropriate one. CMake should take care of building
the dependencies using the "target_link_library" links.

However I may have misunderstood what you want?

Could you tell us what you want and may be send us some CMakeLists.txt
you already tried?


--
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] How to differ?

2010-10-29 Thread Eric Noulard
2010/10/29 Thomas Lehmann :
> At the end you can see a version which was working well
> but we found it somewhat complicated with the paths.

I did not see any attachment or inline copy of CMakeLists.txt

[...]

>> and for each app there will be some
>> projects/apps//CMakeLists.txt which contains
>> add_executable( )
>> target_link_library( )
>> include_directories(${CMAKE_SOURCE_DIR}/libs/)
>
> Yes. But how do that program generate the libraries
> when they are not build yet?

Because CMake should handle the dependency because
of the target_link_library.

By the way which CMake version do you use?
And which CMake Generator (Makefile, Visual Studio project...)
on which platform (Linux, Windows, MacOS etc...)

>> from this structure you should be able to build part or all of the
>> target
>> just by calling the appropriate one. CMake should take care of building
>> the dependencies using the "target_link_library" links.
>>
>
> cmake can be used for different paths in a source tree.
>
> Trying to create both apps both are trying to build both
> libraries on different locations - cmake complains.

What do you mean by "complains"?
Could you copy/paste the complain you get from CMake?

> The command after here fails without handling to use
> "link_directories" or "add_subdirectory" properly:
>
> /tmp/obj> cmake /projects/apps

You could do:

/tmp/obj> cmake /projects

the

1) rebuild all
2) build a set of applications
3) build just one application


> 1) I can rebuild all
> 2) I can build a set of applications
> 3) I can build just one application
>
> Independent on what scenario I use I want to ensure that
> all dependencies are built and used.

Then you should launch CMake on the whole set of (lib, apps etc...)
and only build what you want.

-- 
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] rpath business: CPack / running binaries in the build dir

2010-11-02 Thread Eric Noulard
2010/11/2 Szilárd Páll :
> Hi,
>
> In order to be able to run binaries linked dynamically to some
> libraries from the same project the rpath in the build directory has
> to point to the lib directory in the build directory. However, this
> brakes CPack which seems to require the
> CMAKE_BUILD_WITH_INSTALL_RPATH set on to work flawlessly.
>
> Is there any way to rewrite rpath while CPack-ing and installing? Note
> that platform independence is priority #1.

Did you read this?
http://www.cmake.org/Wiki/CMake_RPATH_handling



-- 
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] CMake 2.8.3-rc4 ready for testing!

2010-11-03 Thread Eric Noulard
2010/10/30 David Cole :
> The CMake 2.8.3 release candidate stream continues!
> You can find the source and binaries here:
> http://www.cmake.org/files/v2.8/?C=M;O=D
>
> EXCEPT: There are not yet Irix or Sun pre-built binary
> installers available for CMake 2.8.3-rc4. There is a
> failing (HTML documentation validity checking) test on
> some platforms that appears to be unrelated to any CMake
> source code changes. That test failure is preventing the
> release building process from completing today on those
> platforms. If that issue clears up soon, I'll re-do the
> installers on those platforms. If not, just use rc3, or
> build from source. We'll address this before the final
> release.
>
> This will be the LAST release candidate for 2.8.3
> unless a major regression is reported. So please
> try it on your projects and let us know right away
> about any problems.

I "may" have a problem with Visual Studio 2010 generator.
The concerned project CERTI (https://savannah.nongnu.org/projects/certi)
builds fine on on several using CMake.

But when we try to build CERTI with CMake 2.8.2 (or 2.8.3rc4) we get
a solution file which fails to load completely because because one vcproj
contains an apparently mis-closed statement:

offending lines are those one:
[...]


  $(IntDir)/sha1.obj


[...]

i.e. the 
is closed by a
   

The corresponding source code may be found there:
http://cvs.savannah.gnu.org/viewvc/certi/?root=certi.

I'm not sure I will have the time to build a smaller example.

Note that the same source tree is working well using any
other CMake generators (Visual Studio or Code::Blocks etc...)
so the problem seems to be particular to VS2010.



-- 
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] CMake 2.8.3-rc4 ready for testing!

2010-11-03 Thread Eric Noulard
2010/11/3 Bill Hoffman :
>
> The reason this is showing up is because they are compiling a .h file:
>
> LIST(APPEND LIBHLA_EXPORTED_INCLUDES sha1.h)
> set_source_files_properties(sha1.c sha1.h PROPERTIES LANGUAGE "C")
> SOURCE_GROUP("Source Files\\Hash" FILES ${LIBHLA_HASH_SRCS})
>
>
> The sha1.h is being set to a C source file.  It is a bug, and the patch
> should fix it.

I'll try the patch.

> However, seems odd to be compiling a .h file.

What do you mean by "compiling" a header?

I usually do

add_library(mylib file1.c file1.h file2.c file2.h)
or
add_executable(myexe mysource.c anyother.h)
etc...

what's wrong/odd with that I thought CMake would sort it out
what is an header and what is not ?

Or do you mean that the
set_source_files_properties(sha1.c sha1.h PROPERTIES LANGUAGE "C")

is telling CMake that "sha1.h" should be compiled?

I thought I was (because I'm the culprit) telling CMake that thoses file
were C files (either header or to-be-compiled sources)?

Am I wrong?


-- 
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] CMake 2.8.3-rc4 ready for testing!

2010-11-03 Thread Eric Noulard
2010/11/3 David Cole :
>>
>> It should be fine. CMake should handle .h files that have this property
>> set. We should fix it. (And we will -- probably in the 2.8.4 release.)

OK no problem.

Sorry for being late to test that combination but I'm not usually
using Windows box
and even more rarely VS2010...

>> But, for now, you should be able to work around it on your side by
>> removing the sha.1 from the list of files in your
>> set_source_files_properties call.

True just tested that. It works.

> I meant "...removing the sha1.h from ..."

I inferred that too :-)


-- 
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] CMake 2.8.3-rc4 ready for testing!

2010-11-04 Thread Eric Noulard
2010/11/4 Bill Hoffman :
 But, for now, you should be able to work around it on your side by
 removing the sha.1 from the list of files in your
 set_source_files_properties call.
>>
>> True just tested that. It works.
>>
>>> I meant "...removing the sha1.h from ..."
>>
>> I inferred that too :-)
>>
>>
> If you don't want that file to be compiled, then setting the language to "C"
> is wrong, and is likely to produce unexpected behavior.  It is telling CMake
> that the file is a C file and it should be compiled. CMake should of course
> not create a VS project that fails to load because of this, but it might do
> other odd things when you try and treat a .h file like it is a .c file.

Ok I get it, but note that I had a "semantic" issue.

This project is a C++ project with "some" C files.
There are both headers AND source file.

In my mind  "source" file may either be a header or a body (i.e.) to
be compiled file.
So  I wazs trying to tell CMake that this header is a C one in order to be
"consistent".

The "set_source_files_properties" says :
"Set properties on a file."
and later on:

"LANGUAGE (string) CXX|C will change the default compiler used to
compile the source file."

now I get that a "source file" is-a to be compiled file.

So my mistake may be was an "english understanding"  issue of what is
a "source file".

I continue to think that it would be valuable to tell CMake that such "header"
is a C/Fortran/CXX woiuld be nice.

It may even become necessary if pre-compiled header are to be supported.

So I now understand my mistake but I'm not on your side when you say
"setting the language to "C" is wrong"

I think it should be just OK, setting the "LANGUAGE" of a file shouldn't imply
this file has to be compiled.

-- 
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] CMake 2.8.3 available for download

2010-11-04 Thread Eric Noulard
2010/11/4 Micha Renner :
> Unpacking cmake-2.8.3.tar.gz, cmake-2.8.3-Linux-i386.tar.gz results in
> the following error message of the archive manager:
> gzip: stdin: not in gzip format
> tar: Child returned status 1
> tar: Error is not recoverable: exiting now

Those are ok for me.
Don't you have a download issue ? (which may be uncompressing on the fly)?

Could you try
$ wget http://www.cmake.org/files/v2.8/cmake-2.8.3-Linux-i386.tar.gz
then
$ file cmake-2.8.3-Linux-i386.tar.gz
and
$ tar ztvf cmake-2.8.3-Linux-i386.tar.gz


-- 
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] [cmake-developers] Bug fix requests for the *next* release of CMake...

2010-11-04 Thread Eric Noulard
2010/11/4 David Cole :
> Hi all,
>
> Now that we have released CMake 2.8.3, *now* would be a great time to
> prioritize bug fixes for the next release of CMake.
>
> Replies requested. Read on. Just a short reply with bug numbers or links to
> the bugs is all we need here. Please move specific discussions into the bugs
> themselves or start a new thread to talk about it... Replies on this thread
> should just be a collector for bug numbers.

http://cmake.org/Bug/view.php?id=11404
http://cmake.org/Bug/view.php?id=7645 + same idea for Debian Package
see ML
http://www.cmake.org/pipermail/cmake/2010-October/040321.html
and http://purplekarrot.net/blog/dputCMake.html
+
Add More CTest  test for CPack generators inside the CMake tree.


-- 
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] header files with visual studio

2010-11-06 Thread Eric Noulard
2010/11/6 Pedro d'Aquino :
> On Friday, November 5, 2010, Oliver kfsone Smith 
>>
>> Thanks for the detailed response, Michael :)
>>
>> So, the question is actually:
>>
>> Is there a way to have CMake automatically add included headers to visual 
>> studio project files or do you need to use a dependency system to generate 
>> the lists by hand?
>
> Can't you just include "*.h" "*.hpp"? I find it scales much better
> that listing each file.

Initially it may be a pain to list them but after a while its generally better
to manually keep track of file (dis)appearing in your source tree.
(which is usually what you do when using an IDE without CMake)

I.e. if those files are/were added "by hand" into the build system then they
must but tracked by explicit list in CMakeLists.txt.

The only case (I see) you may faithfully glob for *.h *.whatever is when
those are generated files.

Not doing that means

"I don't care about source file which are added/removed
 I just want to compile those"

**MY** opinion is that this way of looking to source code is wrong.

That said I fully understand that the to CMake transition may be painful when
the project is big.

-- 
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] help with learning add_library

2010-11-06 Thread Eric Noulard
2010/11/7 luxInteg :
> I tried the following:-
>
> ADD_LIBRARY(LearnCMAKE-shared SHARED   file1.c file2.c )
> ADD_LIBRARY(LearnCMAKE-static STATIC  file1.c file2.c )
> SET(var "")
> FOREACH(var DINT DLONG)
>        SET_SOURCE_FILES_PROPERTIES( file1.c file2.c
>    PROPERTIES COMPILE_DEFINITIONS ${var})
> ENDFOREACH(var)
> SET_TARGET_PROPERTIES(LearnCMAKE-shared LearnCMAKE-static
>    PROPERTIES OUTPUT_NAME LearnCMAKE)
>
> but my compile logs only show lines with  "-DDLONG -O3 "
> and one with  "-DDINT -O3"
>
> and the generated libs are about half the size they should be.
>
> advice would be appreciated

I think you cannot use **the same** file properties on a source file
and expect CMake will compile the file twice for the same target.
If you want to compile the same source file twice with different compile flags
**FOR THE SAME TARGET** you have to copy this file

configure_file(file1.c file1-long.c @COPYONLY)
SET_SOURCE_FILES_PROPERTIES(file1.c PROPERTIES COMPILE_DEFINITIONS "-DINT")
SET_SOURCE_FILES_PROPERTIES(file1-long.c PROPERTIES
COMPILE_DEFINITIONS "-DLONG")

** same for file 2 **
ADD_LIBRARY(LearnCMAKE-static STATIC file1.c file1-long.c file2.c file2-long.c)
ADD_LIBRARY(LearnCMAKE-shared SHARED file1.c file1-long.c file2.c file2-long.c)

note however that you CAN compile the **same file** twice with differents flags
if it is for **DIFFERENT** targets. You can use "set_target_properties".
i.e.
ADD_LIBRARY(LearnCMAKE-int file1.c file2.c)
ADD_LIBRARY(LearnCMAKE-long file1.c file2.c)

set_target_properties(LearnCMAKE-int PROPERTIES COMPILE_FLAGS "-DINT")
set_target_properties(LearnCMAKE-long PROPERTIES COMPILE_FLAGS "-DLONG")

i.e. AFAIK compiling the **same** source file twice for the **same** target
is unsupported.


-- 
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] cmake gfortran-libs linking x86_64

2010-11-07 Thread Eric Noulard
2010/11/7 luxInteg :
> Greetings,
>
>
>
> I am learning cmake   I have the following gfortran libraries on my computer:-
>
> rt [ ~ ]$
> rt [ ~ ]$ ls -l  /usr/lib/*gfortran*
> -rw-r--r-- 1 root root 8489924 Jul 27 12:19 /usr/lib/libgfortran.a
> -rwxr-xr-x 1 root root     952 Jul 27 12:19 /usr/lib/libgfortran.la
> lrwxrwxrwx 1 root root      20 Jul 27 12:18 /usr/lib/libgfortran.so ->
> libgfortran.so.3.0.0
> lrwxrwxrwx 1 root root      20 Jul 27 12:19 /usr/lib/libgfortran.so.3 ->
> libgfortran.so.3.0.0
> -rwxr-xr-x 1 root root 4104076 Jul 27 12:20 /usr/lib/libgfortran.so.3.0.0
> rt [ ~ ]$
> rt [ ~ ]$ ls -l /usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.2/*gfortran*
> -rw-r--r-- 1 root root 8902 Jul 27 12:18 /usr/lib/gcc/x86_64-unknown-linux-
> gnu/4.4.2/libgfortranbegin.a
> -rwxr-xr-x 1 root root  923 Jul 27 12:18 /usr/lib/gcc/x86_64-unknown-linux-
> gnu/4.4.2/libgfortranbegin.la
> rt [ ~ ]$
>
> QUESTION1: are there envars  to set in a  cmake project  to  enable linking to
> these programs  and if so how so?
> QURSTION2: If QUESTION1 is {no} can one  say set  F_LDFLAGS="-L/usr/lib/ -
> L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.2/"  and would it make sense in a
> cmale project?
> QUESTION3: libgfortranbegin is avaibale only as a static library,   can
> fortran shared libraries   still be linked to it?
>
> advice would be appreciated.

What are you trying to do ?

1) Compile & Link some Fortran source for a Fortran project ?
2) Compile & Link some mixed language project like C/Fortran or C++/Fortran ?

Usually when using Fortran you should add

enable_language(Fortran)

for mixed language programming you have the
FortranCInterface cmake module:
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#module:FortranCInterface

If you search the ML archive you will find many discussions related to
Fortran Programming.

-- 
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] help with learning add_library

2010-11-08 Thread Eric Noulard
2010/11/8 luxInteg :
> On Saturday 06 November 2010 23:08:29 Eric Noulard wrote:
>
>>
>> I think you cannot use **the same** file properties on a source file
>> and expect CMake will compile the file twice for the same target.
>> If you want to compile the same source file twice with different compile
>> flags **FOR THE SAME TARGET** you have to copy this file
>>
>
>> SET_SOURCE_FILES_PROPERTIES(file1-long.c PROPERTIES
>> COMPILE_DEFINITIONS "-DLONG")
>
>
>> ** same for file 2 **
>> ADD_LIBRARY(LearnCMAKE-static STATIC file1.c file1-long.c file2.c
>> file2-long.c) ADD_LIBRARY(LearnCMAKE-shared SHARED file1.c file1-long.c
>> file2.c file2-long.c)
>
> BUT
> suppose I decide to set   file1.c and file2.c   as some variable "FILES" and I
> want to use a preprocessor say DLONG
>  could I do the following?
>
> set(FILES file1.c file2.c )
> SET_SOURCE_FILES_PROPERTIES(${FILES} PROPERTIES COMPILE_DEFINITIONS "-DLONG")

Off course you can
BUT you cannot set the SAME PROPERTY twice for the same file.
So if you have to do so (compile fileX.c with BOTH -DINT and DLONG) then
you have to do some sort of loop with CMake or
populate 2 CMake variable

SRC_FILES_LONG
and
SRC_FILES_INT
with the list of appropriate file.

If you manipulate list have a look at the CMake builtin "LIST" command.



-- 
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] help with learning add_library

2010-11-08 Thread Eric Noulard
2010/11/8 luxInteg :
>>
>> If you manipulate list have a look at the CMake builtin "LIST" command.
>
> I   had a look at lists  on this page
> http://www.cmake.org/Wiki/CMakeMacroListOperations

You should reallty use **builtin** list
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:list
and not possibly OBSOLETE MACRO.

unless you really have to use a CMake version which does not support "list"

-- 
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] header files with visual studio

2010-11-11 Thread Eric Noulard
2010/11/10 Oliver kfsone Smith :
> Eric Noulard said the following on 11/6/2010 6:20 AM:
>>
>> Initially it may be a pain to list them but after a while its generally
>> better
>> to manually keep track of file (dis)appearing in your source tree.
>> (which is usually what you do when using an IDE without CMake)
>>
>> I.e. if those files are/were added "by hand" into the build system then
>> they
>> must but tracked by explicit list in CMakeLists.txt.
>>
>> The only case (I see) you may faithfully glob for *.h *.whatever is when
>> those are generated files.
>>
>> Not doing that means
>>
>> "I don't care about source file which are added/removed
>>  I just want to compile those"
>>
>> **MY** opinion is that this way of looking to source code is wrong.
>
> You appear to be confusing Revision Control / Asset Management with source
> code editing. And while for smaller projects that may make some sense, it
> breaks very quickly as the project size scales up.

I don't think so, but I'll try to explain myself.

> The solution file for (just) our server systems has 21 top-level projects
> (not counting ALL_BUILD, INSTALL and ZERO_CHECK). Because of the high degree
> of code reuse and overlap, all of the host, client and miscellaneous source
> codes sit side-by-side (although not in any one single directory).
>
> So importing "*/*.{h,hh,hpp}" into the CMakeLists file is nonsensical.

Having a lot of source code re-use from "source modules" that can be shared
between several projects is off course a necessary goal when your source
code base grows and the set of projects using those goes along the same curve.

My experience is in this case you may have mainly two kinds of re-use:

A) "external-like" re-use were the reused module is an autonomous
  [set of] library and executable.
 CMake may handle this using "ExternalProject_Add" module
 and the module may have his own CMakeLists.txt containing the toplevel
 PROJECT(...)

B) "internal-like" re-use. You may import the source but the imported
 source may not be compiled autonomously and should be plugged
 somewhere in the project source tree using the module.

 In this case ecah "internal-like" module may be shipped with
 a SourceDescription.cmake file which (manually) define appropriate
 set of CMake VAR (_SRC_FILES, _HEADER_FILES, ...)
 which can be included by the upper-level using project.

A-type project are edited (and source-controlled) on their own.
B-type project may be edited in any user project,
  how you handle source control in this case depends on your organisation
  and project inter-dependency management.

> What I was hoping to achieve was a "Header Files" folder along side each
> "Source Files" folder so that the headers were pertinent to any given
> project within a solution.

Does CMake "source_group"  will do the jobs if each sub-project
is defining its list of __FILES?

Now, I admit I'm not a usual Visual Studio user so you are pretty right with
the fact I didn't face any performance issue on big project with VS.

I did work on relatively big source project with many imported modules
(external-like or internal-like) but we were not using any IDE  just
emacs/vi etc and a big set of Makefiles (no CMake usage at that time).

-- 
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] header files with visual studio

2010-11-14 Thread Eric Noulard
2010/11/13 Oliver kfsone Smith :
> I mostly work with emacs/vi and - prior to CMake - Makefiles. I'm still
> mostly working with emacs/vi, but I also do a fair amount of work with
> Visual Studio and CodeBlocks, primarily when I need to test client
> interactions with server processes.
>
> Manually maintaining duplicated lists of #includes is data duplication: Like
> manually maintaining dependency lists. If we had to do that with CMake, well
> I doubt we'd be having this conversation in the first place because we
> probably wouldn't be /using/ CMake.

OK and off course you are right.

> So I don't understand why you would feel differently about having those
> lists automatically transcribed to the resultant IDE solution/project files.

You are right again and I was not looking at that this way.
I do (may be did?) have mental dichotomy between the "build process"
(for which I expect just like you an automatic dependency handling from CMake)
and "source management process" for which *.h
(or any #included file) and/or *.c (or any "compiled" file) are just source
like others which I have to manage explicitely,
either with SCM tool or inside CMakeLists.txt.

But may be I shall step back and just think differently about it and even if
I need to explicitly use SCM for headers may be they shall just "disappear"
from CMakeLists.txt?
May be the public "exported" headers would still appear in the CMakeLists.txt
but most of them can just go away.

I think Michael did get your point and I didn't, sorry about that.

Now re-reading the Michael post it seems that having some hook
(or property)
to get dependency list from a particular file (or target) should be
the way to go.

There has been some discussion on the list about improvement
of the dependency scanner, this kind of idea may be examined there.
May be it's worth filing a feature request on this subject.

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


[CMake] CPACK_MONOLITHIC_INSTALL not handled at runtime?

2010-11-14 Thread Eric Noulard
Hi All,

I'm working on CPackRPM for supporting componentized RPM:
http://public.kitware.com/Bug/view.php?id=7645
(preliminary support has been pushed to next yesterday)

then another CPack-component related bug appeared:
http://public.kitware.com/Bug/view.php?id=11452

So I think that

1) May be generating a componentized installer "by default" was a mistake
for compatibility reason? YES/NO

2) User should have a way to request non-componentized package
even for component-aware CPack Generator.
I though CPACK_MONOLITHIC_INSTALL was usable but it is not
as (I think) it should because it is only evaluted AT CMake-time
even it would still be useful AT CPack-time.

Meaning:

   a) if CPACK_MONOLITHIC_INSTALL is set at CMake-time
ALL CPack generator will produce non-component package

   b) if CPACK_MONOLITHIC_INSTALL is set at CPack time
   (but not at CMake-time) only the concerned generator may
   generate non-component install.

So my question is twofold:

1) Shall we step back and may be setup a CMake policy for
enabling component installer?
If we go for a policy may be someone can help me with this
because I did never add a new policy mayself.

2) Shall I propose a patch for supporting 2b) or is there something
I miss regarding this issue?

-- 
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] CPACK_MONOLITHIC_INSTALL not handled at runtime?

2010-11-14 Thread Eric Noulard
2010/11/14 Eric Noulard :
> Hi All,
>
> I'm working on CPackRPM for supporting componentized RPM:
> http://public.kitware.com/Bug/view.php?id=7645
> (preliminary support has been pushed to next yesterday)
>
> then another CPack-component related bug appeared:
> http://public.kitware.com/Bug/view.php?id=11452

[...]


>   b) if CPACK_MONOLITHIC_INSTALL is set at CPack time
>       (but not at CMake-time) only the concerned generator may
>       generate non-component install.

I did open a feature request for that:
http://www.vtk.org/Bug/view.php?id=11458

I did provide a patch, which is somehow straightforward:
I'll wait for feedback before pushing this to next :-]

-- 
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] CPACK_MONOLITHIC_INSTALL not handled at runtime?

2010-11-14 Thread Eric Noulard
2010/11/14 Vladislav Vaintroub :
>
> [skip]
>> 1) Shall we step back and may be setup a CMake policy for
>>     enabling component installer?
>>     If we go for a policy may be someone can help me with this
>>     because I did never add a new policy mayself.
>
> Sounds like a good idea. On the other hand, just assuming 
> CPACK_MONOLITHIC_INSTALL=1  by default for
> archives (ZIP, TGZ) and produce
> components only if explicitly  requested with CPACK_MONOLITHIC_INSTALL=0 
> would be fine with me.
> I imagine, this is what many users would want, but I might be mistaken.

Ok I think the idea is good but I propose some slightly more elaborate scheme.

Each CPackGenerator may support or not component install.
Now it's not because a generator is able to produce "componentized" package that
it should be it's default behavior (even if the user specified
COMPONENT in its CMakeLists.txt)

Thus for each generator which support component install there is an associated
default behavior which is to go either way.

If a user wants to enforce the non default behavior (either way) it may do so
by setting

CPACK__MONOLITHIC_INSTALL
CPACK__COMPONENT_INSTALL
or
CPACK__INSTALL_BEHAVIOR=MONOLITHIC
CPACK__INSTALL_BEHAVIOR=COMPONENT

we need both because default behavior for existing installer are
or will be differents (NSIS vs ZIP).


if ones want to GLOBALLY enforce either way then:

CPACK_MONOLITHIC_INSTALL
CPACK_COMPONENT_INSTALL
or
CPACK_INSTALL_BEHAVIOR=MONOLITHIC
CPACK_INSTALL_BEHAVIOR=COMPONENT
could be set.

Non component-aware generator will ignore those
(as of today).

Those vars may be set at CMake-time or at CPack-time.

What do you think?

I personnally think this scheme is relatively simple and robust
and it would be easy to maintain backward compatibility without
even have to introduce a new cmake policy.

-- 
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] CPACK_MONOLITHIC_INSTALL not handled at runtime?

2010-11-14 Thread Eric Noulard
2010/11/14 Vladislav Vaintroub :

>> Those vars may be set at CMake-time or at CPack-time.
>>
>> What do you think?
>
> Yes, sounds like a good idea, it allows the most flexibility.   Re. variables 
> , I guess  CPACK_MONOLITHIC_INSTALL={ON|OFF} and
> CPACK__MONOLITHIC_INSTALL ={ON|OFF} would already cover all 
> possible scenarios.
> I.e MONOLITHIC_INSTALL=OFF  is the same
> as component install = ON, right?

It could be if We can check that MONOLITHIC_INSTALL is not set at ALL.

We need 3 state:
- nothing set --> default builtin behavior for each generator
- MONOLITHIC_INSTALL=ON --> default to monolithic for all generators
- MONOLITHIC_INSTALL=OFF or COMPONENT_INSTALL=ON --> default to
component for all generators

I'll have to check whether if it's easy or not to distinguish between
MONOLITHIC_INSTALL=OFF and MONOLITHIC_INSTALL not set.

Even if it's possible I think it would be easier to think about
"positive" logic than negative one.
The better way to handle the 3-state case may be:
CPACK_INSTALL_BEHAVIOR=MONOLITHIC | COMPONENT | DEFAUILT | 

but historically they are more ON/OFF YES/NIO vars in CMake than
multi-valued (enum) vars.
-- 
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] CPack general question and example

2010-11-15 Thread Eric Noulard
2010/11/15 David Doria :
> I just heard about CPack and started playing with it.

Which version of CMake/CPack are you using?

> I tried to make an RPM of a simple VTK program:
>
> http://www.cmake.org/Wiki/CMake/CPackExample
>
> When I run 'make package', I get an error:
>
> CPack Error: Problem copying the package:
> /home/doriad/CPackTest/bin/_CPack_Packages/Linux/RPM/DistanceBetweenPoints-0.1.1-Linux.rpm
> to /home/doriad/CPackTest/bin/DistanceBetweenPoints-0.1.1-Linux.rpm
> CPack Error: Error when generating package: DistanceBetweenPoints
> make: *** [package] Error 1
>
> If I leave out the
> SET(CPACK_GENERATOR "RPM")

More information about CPack RPM (and others) is there:
http://www.vtk.org/Wiki/CMake:CPackPackageGenerators

> line, there are no errors, but the .tar.gz file that is created seems
> to be empty. Am I missing something?

Yes probably,
CPack will package objects (FILE, TARGET, etc..) which are found
in INSTALL rules?
Do you have INSTALL statements in your CMakeLists.txt

> On a bigger question - what can I expect to be contained in the RPM?
> EVERYTHING required to run my program (which will include all of VTK
> (or at least the required bits?))? I'm just trying to get a handle on
> when and why I would want to do this.

Nope.
You won't get the dependency automatically (at least not with current CPack RPM)

You may look at BundleUtilities CMake module for that purpose, but
I don't know how far it can go.


-- 
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] setting the COMPILE_FLAGS property causes VS to start compiling header files

2010-11-15 Thread Eric Noulard
2010/11/15 James Bigler 
>
> If I set a COMPILE_FLAGS property on a header file via 
> set_source_files_properties, CMake decides that these header files now need 
> to be compiled (i.e. not treated as header files).
>
> Is this the intended behavior?
>
> I'm using both 2.8.1 and 2.8.3 on Windows with VS 2008 SP 1.

This linked with an already filed bug:
http://www.vtk.org/Bug/view.php?id=11404

--
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] CPack general question and example

2010-11-16 Thread Eric Noulard
2010/11/16 David Doria :
> Great, it's working.  The only thing that was required was:
>
> SET(CPACK_DEBIAN_PACKAGE_MAINTAINER "David Doria")
>
> Here is the working example:
> http://www.cmake.org/Wiki/CMake/CPack/Examples/Linux/DEB
>
> The page you sent
> (http://www.vtk.org/Wiki/CMake:CPackPackageGenerators#DEB_.28UNIX_only.29)
> has a lot of variables marked "mandatory", but they all seem to have
> reasonable defaults except the MAINTAINER. Could this terminology be
> modified?

Yes it should, you may correct the Wiki yourself but check the CPackDeb.cmake
file before doing modification.

Normally the most up-to-date documentation is within the module itself
(for the module which define the doc)

You may see it using:
cmake --help-module CPackDeb
cmake --help-module CPackRPM

> Also, (I think) there are some typos that I don't feel confident
> correcting myself:
>
> if CPACK_DEBIAN_PACKAGE_VERSION is not set CPACK_PACKAGE_VERSION
> ->
> If CPACK_DEBIAN_PACKAGE_VERSION is not set, it will default to
> CPACK_PACKAGE_VERSION
>
> if CPACK_DEBIAN_PACKAGE_NAME is not set, CPACK_PACKAGE_NAME (lower
> case) will be used
>
> I strongly suggest that we create
> http://www.cmake.org/Wiki/CMake/CPack/Examples/Linux/RPM
> http://www.cmake.org/Wiki/CMake/CPack/Examples/Linux/TAR
> http://www.cmake.org/Wiki/CMake/CPack/Examples/Windows/EXE (or
> whatever it is called)

Go ahead do it.
May be the name should be the same as the generator name,
you may get the list of generators (supported on your platform) by running:
cpack --help

You may be interested to know that there is a feature request for
enhancing CPack doc:
http://public.kitware.com/Bug/view.php?id=10067

If you want to help I think you would be welcomed.

> so that it is very clear (one can copy/paste a solution) how to do this.


-- 
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] Fortran 90 modules not rebuilt

2010-11-16 Thread Eric Noulard
2010/11/16 Belcourt, K. Noel :
>
> On Nov 16, 2010, at 2:05 PM, Belcourt, K. Noel wrote:
>
>> On Nov 16, 2010, at 1:59 PM, Brad King wrote:
>>
>>> On 11/16/2010 01:11 PM, K. Noel Belcourt wrote:

 I've attached my project's top-level Makefile.  I'm trying to force
 all the modules in the project to build first so I created a single
 library called modules that contains all my Fortran 90 module files.
 I'm invoking the Makefile explicitly passing the modules as the
 target to build (so I can build a clean project in two steps: make
 modules ; make)
>>>
>>
>>> The Fortran module dependencies implementation is hidden inside the
>>> Makefile generators.  There is no API to access any of its timestamp
>>> files or scanning rules.
>
> What's interesting is that in a project that's fully update to date, running
> the make modules command gives this curious output:
>
> S896822:tools kbelco$ make modules
> [ 16%] Built target util
> [ 19%] Built target tp
> [ 25%] Built target spr
> [ 35%] Built target rn2
> [ 61%] Built target rn1
> [ 61%] Built target mp
> [100%] Built target modules
>
> which is the same list of libraries in these SUBDIRS commands in the
> top-level CMakeLists.txt file (in reverse order).

Is there any reason you are using SUBDIRS instead of ADD_SUBDIRECTORY?

SUBDIRS is deprecated and as far as I remember it has a different
"search-ordering" than add_subdirectory

> There's a single library
> in each of these subdirs of the same lower-cased name.
>
> ...
> SUBDIRS(Modules)
> SUBDIRS(MP)
> SUBDIRS(Rn1)
> SUBDIRS(RN2)
> SUBDIRS(SPR)
> SUBDIRS(TP)
> SUBDIRS(Util)
>
> So it looks like the subdirs command plays a role in this behavior.

try replacing your SUBDIRS with add_subdirectory.


-- 
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] Howto to work with variables from central makefiles....

2010-11-17 Thread Eric Noulard
2010/11/17 Thomas Lehmann 
>
> Hi all,
>
>
>
> for an automatically forced include I have provided an
>
> option like this:
>
>
>
> set(WIN32_SPEC ${CMAKE_CURRENT_SOURCE_DIR}/../../libs/global/win32_spec.h)

May you could use an absolute reference using

${PROJECT_SOURCE_DIR}/libs/global/win32_spec.h

if your project is name TOTO
(from the PROJECT(TOTO CXX) statement)
you use

${TOTO_SOURCE_DIR}/libs/global/win32_spec.h.

>
> add_definitions(-FI ${WIN32_SPEC})
>
>
> But when including this central file (find_package) the variable 
> CMAKE_CURRENT_SOURCE_DIR
> changes and then the path and filename of the header is wrong.
>
>
>
> How to proceed best?
> Can I avoid that for those “set” statement the variable is not overwritten by 
> those
> files including this central makefile?

You may use a CACHED variable
set(WIN32_SPEC ${PROJECT_SOURCE_DIR}/libs/global/win32_spec.h CACHE
FILEPATH "Central Include")

the first calling this will set the value then other set will be ignored.
If you want to override a CACHE var value you'll have to use FORCE set option.



--
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] codesourcery integration

2010-11-17 Thread Eric Noulard
2010/11/17 Andrea Galeazzi :
> I'm facing the problem of using the cross compile toolchain of CodeSourcery.
> My host system in Windows and my target is ARM-Linux.
> I red this tutorial http://www.cmake.org/Wiki/CMake_Cross_Compiling and I
> tried to do something similar:
> # this one is important
> SET(CMAKE_SYSTEM_NAME Linux)
> #this one not so much
> SET(CMAKE_SYSTEM_VERSION 1)
>
> # specify the cross compiler
> SET(CMAKE_C_COMPILER   C:/Programmi/CodeSourcery/Sourcery G++
> Lite/bin/arm-none-linux-gnueabi-gcc.exe)
> SET(CMAKE_CXX_COMPILER C:/Programmi/CodeSourcery/Sourcery G++
> Lite/bin/arm-none-linux-gnueabi-g++.exe)

You should escape or "quote" file path with embedded space
try

SET(CMAKE_C_COMPILER   "C:/Programmi/CodeSourcery/Sourcery G++
Lite/bin/arm-none-linux-gnueabi-gcc.exe")
SET(CMAKE_CXX_COMPILER   "C:/Programmi/CodeSourcery/Sourcery G++
Lite/bin/arm-none-linux-gnueabi-g++.exe")

> # where is the target environment
> SET(CMAKE_FIND_ROOT_PATH C:/Programmi/CodeSourcery/Sourcery G++ Lite)

Same here
SET(CMAKE_FIND_ROOT_PATH "C:/Programmi/CodeSourcery/Sourcery G++ Lite")

[...]

> What's wrong?
> Furthermore if I want to use Eclipse, what kind of Eclipse makefile should I
> choose?

I think that all options concerning Eclipse + CMake are described here:
http://www.cmake.org/Wiki/CMake:Eclipse_UNIX_Tutorial

-- 
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] Problems with parallel builds

2010-11-18 Thread Eric Noulard
2010/11/18 Denis Scherbakov :
> Dear All,
>
> I am using CMake 2.8.1 on Linux x86. I have a project that needs to be built 
> two times. One with -fPIC, the other - without. The project depends on header 
> files that need to be generated by an external script.
>
> When I build this project with several parallel jobs (gmake -j5, for example) 
> to my disappointment CMake calls external script several times so at the end 
> I get corrupted header files.

Could you give us the exact CMake rule/command you use to generate
those headers?

configure_file?
add_custom_command?
add_custom_target?
execute_process?
... combination of those ?

> Does anybody know a cross-platform way of implementing a mutex (or something 
> like that) to make sure that
> scripts that generate files are called only once?
>
> So far for me parallel builds do not work with CMake at all.

I did never had any trouble with parallel building with CMake on Linux
with makefile generator so far.
For build host ranging from 1 processors to 4 processors with various -j values.

-- 
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] Problems with parallel builds

2010-11-18 Thread Eric Noulard
2010/11/18 David Cole :
> On Thu, Nov 18, 2010 at 1:08 PM, Denis Scherbakov
>  wrote:
>> Here is a sample CMakeLists.txt to illustrate that two custom targets cannot 
>> depend on each other:
>>
>> PROJECT(BUG C)
>>
>> CMAKE_MINIMUM_REQUIRED(VERSION 2.8)
>>
>> ADD_CUSTOM_COMMAND(
>>  OUTPUT  "${CMAKE_CURRENT_BINARY_DIR}/fileOne"
>>  COMMAND "${CMAKE_COMMAND}"
>>     ARGS "-E"
>>          "touch"
>>          "${CMAKE_CURRENT_BINARY_DIR}/fileOne")
>>
>> ADD_CUSTOM_TARGET(targetFileOne DEPENDS 
>> "${CMAKE_CURRENT_BINARY_DIR}/fileOne")
>>
>> ADD_CUSTOM_COMMAND(
>>  OUTPUT  "${CMAKE_CURRENT_BINARY_DIR}/fileOne-s"
>>  COMMAND "${CMAKE_COMMAND}"
>>     ARGS "-E"
>>          "touch"
>>          "${CMAKE_CURRENT_BINARY_DIR}/fileOne-s")
>>
>> ADD_CUSTOM_TARGET(targetFileOneS ALL DEPENDS targetFileOne 
>> "${CMAKE_CURRENT_BINARY_DIR}/fileOne-s")
[...]


> Instead of:
>> ADD_CUSTOM_TARGET(targetFileOneS ALL DEPENDS targetFileOne 
>> "${CMAKE_CURRENT_BINARY_DIR}/fileOne-s")
>
> Try:
> ADD_CUSTOM_TARGET(targetFileOneS ALL DEPENDS
> "${CMAKE_CURRENT_BINARY_DIR}/fileOne-s")
> ADD_DEPENDENCIES(targetFileOneS targetFileOne)

This solution works for me on Linux + CMake 2.8.1 and up.

-- 
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] Dependency not executed, why?

2010-11-18 Thread Eric Noulard
2010/11/19 Thomas Lehmann 
>
> Hi,
>
>
>
> I’ve found an example to use bison and flex in cmake.
>
> I have a static library where I want to add the generated
>
> sources but the dependencies are not triggered. Why?
>
>
>
> project(test)
>
>
>
> include_directories(.
>
>     ${CMAKE_BINARY_DIR}/libs/test)
>
>
>
> add_custom_target(ScannerAndParser echo "Creating scanner.cxx and parser.cxx")
>
>
>
> add_custom_command(
>
>     SOURCE ${CMAKE_CURRENT_SOURCE_DIR}/scanner.l
>
>     COMMAND flex
>
>     ARGS -o ${CMAKE_BINARY_DIR}/libs/test/scanner.cxx
>
>     ${CMAKE_CURRENT_SOURCE_DIR}/scanner.l
>
>     TARGET ScannerAndParser
>
>     DEPENDS ${CMAKE_BINARY_DIR}/libs/test/scanner.cxx
>
>     OUTPUTS ${CMAKE_BINARY_DIR}/libs/test/scanner.cxx)


OUTPUTS (with 'S') should be OUTPUT (without 'S')

I don't know the SOURCE option ?

Which version of CMake do you use?

--
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] Dependency not executed, why?

2010-11-19 Thread Eric Noulard
2010/11/19 Thomas Lehmann :
> - cmake 2.8.2
> - the removing of the 'S' is not solving the problem.

DEPENDS ${CMAKE_BINARY_DIR}/libs/test/parser.cxx
OUTPUTS ${CMAKE_BINARY_DIR}/libs/test/parser.cxx

those two lines are wrong too, I think you cannot not depend on your output.

-- 
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] cpack, deb file & static libraries

2010-11-20 Thread Eric Noulard
2010/11/20 Paolo Zaffino :
> Dear all,
> I builded a deb file using cpack.
> The package work fine but I have a question for you.
> During the compiling (run by cpack command) are generated some static
> libraries that will be included into the package.
> I don't want include the *.a files...do you know a way for exclude them from
> the deb file?

If you don't want to include some targets (including static libs) you should
just not INSTALL(...) them in yor CMakeLists.txt

If you want to install those static libs BUT not include them in the .deb
(which is weird but ok) then there is currently no way to do that.
This can be done by patching CPackDeb.cmake but would you
really want to do that?


-- 
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] cpack, deb file & static libraries

2010-11-20 Thread Eric Noulard
2010/11/20 Paolo Zaffino :
> I try to explain better:
> When I compile my source code, for building the foo executable is needed the
> library bar.a
> Both the files are building during the compile process...into the deb
> package I want include foo but I don't want include bar.a

Building and packaging are separate steps,
usual steps with CMake are:

1) CMake time: this is when cmake runs for configuring the source
2) Build time   : this is when the build tool (make, visual studio,
Xcode, ...) is invoked in order to build,
   i.e. compile the source.
3) Install time  : this is when you install the compiled project
4) CPack time : this is when CPack runs
5) Package install time : this is when the package built with CPack
(RPM, Deb, NSIS, ...)  is running/installed.

Those steps may be calling each other when needed.
E.g. step 2) is calling step 1) whenever a CMakeLists.txt changed.
   step 3) may call step 2) if the installed target are not up-to-date.

CPack when invoked will trigger step 3) using specific destination arguments,
then the package is built.

So there is no such thing as:

"Both the files are building during the compile process...into the deb"

"compile process" is step 2)
Whereas "into the deb" is step 4).

What both Rolf and me said to you is that step 3) is driven by
the INSTALL rules. You should be using an INSTALL rule
for the executable and NOT for the library.

Please show us your CMakeLists.txt it will be easier to help you.

-- 
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] How to rerun cmake if a file changes

2010-11-23 Thread Eric Noulard
2010/11/23 Vladislav Vaintroub :
> Hello,
> we use a text file as input for out build to store version info.  The
> content of this file is
> ./VERSION:
>
> MYSQL_VERSION_MAJOR=5
> MYSQL_VERSION_MINOR=5
> MYSQL_VERSION_PATCH=8
> MYSQL_VERSION_EXTRA=
>
> During cmake run, the information is extracted, parsed,
> CPACK_PACKAGE_FILE_NAME is generated,  and some other things happen, e.g we
> configure a header file mysql_version.h.
> So far, it works nicely, the only problem  with it is that cmake is not
> rerun when this file changes. I made an attempt to fix it by introducing
> custom command and custom target
>
> ADD_CUSTOM_COMMAND(
>   OUTPUT  ${CMAKE_BINARY_DIR}/VERSION.dep
>   COMMAND ${CMAKE_COMMAND} ${CMAKE_BINARY_DIR}
>   COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_BINARY_DIR}/VERSION.dep
>   DEPENDS ${CMAKE_SOURCE_DIR}/VERSION
>   )
> ADD_CUSTOM_TARGET(check_version ALL DEPENDS ${CMAKE_BINARY_DIR}/VERSION.dep)
>
> This seems to work but is not without problems. For example the very first
> build with rerun cmake to generate VERSION.dep.  It takes some seconds with
> Makefiles,  this is not a big problem, however in Visual Studio (I'm using
> VS2010) the very first build would tell me "N  solutions regenerated, you
> want to rebuild?", and then  I clicking "OK" a COM error would popup (the
> build would actually still continue run successfully despite popups and COM
> error).
>
> So the question is if there is a nicer way to accomplish what I want to do.
> I'm aware that if VERSION had CMake syntax with SET(MYSQL_MAJOR_VERSION 5)
> etc, then I could just INCLUDE this file, and this would fix  problems I
> have.  I'm however more interested in a solution that would not force that
> file to be written in CMake syntax.

Do you want to preserve  the "content" of the file or you don't want
to write MYSQL_VERSION_xxx in CMake syntax?

If you only want to preserve this particular file you could generate
it file from your main CMakeLists.txt if you add
version definition in CMakeLists.txt:

SET(MYSQL_VERSION_MAJOR 5)
SET(MYSQL_VERSION_MINOR 5)
SET(MYSQL_VERSION_PATCH 8)
SET(MYSQL_VERSION_EXTRA "")

some VERSION.in file contains;
mysql_version_maj...@mysql_major_version@
mysql_version_min...@mysql_version_minor@
mysql_version_pat...@mysql_version_patch@
mysql_version_ext...@mysql_version_extra@


configure_file(${CMAKE_SOURCE_DIR}/VERSION.in
${CMAKE_BINARY_DIR}/VERSION}
@ONLY)

if "VERSION" file has to be in source tree (would be better to avoid that):

configure_file(${CMAKE_SOURCE_DIR}/VERSION.in
${CMAKE_SOURCE_DIR}/VERSION}
@ONLY)

If you don't want that you should already be generating
mysql_version.h using this file and may be some custom command/target
and I bet the rest of the build depends on mysql_version.h?

So may be your custom command used to generate mysql_version.h
is lacking a file dep?

By the way I cannot find any VERSION file on a fresh update of lp:mysql-server ?

-- 
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] howto re-run file(COPY signature ?

2010-11-24 Thread Eric Noulard
2010/11/24 Dominique Belhachemi :
>> The ${CMAKE_SOURCE_DIR}/copytree.cmake script simply looks like:
>>
>> FILE(COPY ${SRC} DESTINATION ${DST} PATTERN .svn EXCLUDE)
>>
> Thanks, I will see if this works for me.
>
>> Because FILE(COPY ...) copies files and directories only if they are new
> Does it mean it is a bug if FILE(COPY ...) doesn't copy new files?

Not in this case.
FILE( xxx) is CMake-time  command (it runs when CMake runs)

when you do "make" your are at "Build time"
at Build time, cmake may be [automatically] invoked again if some target
(library, executable, custom etc...) NEEDS a re-run because of a dependency.

In your example there is no mean for CMake to know that FILE(COPY ...)
generates a build time dependency.

So when a new file is added either your re-run cmake yourself
or you try Michael proposal
which adds this kind of "build time dependency" using custom target.

-- 
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] providing library information, what's the cmake way

2010-11-24 Thread Eric Noulard
2010/11/24 David Cole :
> On Wed, Nov 24, 2010 at 12:58 PM, Tyler Roscoe  wrote:
>> On Wed, Nov 24, 2010 at 11:41:46AM -0500, David Cole wrote:
>>> On Wed, Nov 24, 2010 at 11:34 AM, Rolf Eike Beer  wrote:
>>> > So I think it is _really_ necessary to go through all the CMake
>>> > documentation items and add a line about when which feature was added.
>>> Adding that information in the documentation would be good, I agree.
>>> (Although quite time consuming and costly for somebody...)
>>
>> Perhaps a good compromise is simply to add version information to all
>> new CMake commands/variables/properties that are added henceforth?
>>
>> Thanks,
>> tyler
>>
>
> That does sound like a good idea.

+1 for this, even if it does not solve all "evolution" problem like
when IF command was added the

IF(TARGET ...) or IF(POLICY ...)

I don't remember when (may the 2.4 --> 2.6 switch)
basically IF command existed before and after the evolution but its
capability was enhanced.

May be adding a list of version for each command may be covering this

like
IF --> start, 2.4.8, 2.6.2, 2.8.3

meaning that IF command was there since "start" and evolved in
2.4.8, 2.6.2, 2.8.3 releases.

If ones want to know the difference one can go and pick up each such release
in order to "generate" documentation diff.

May looks fancy but not knowing that  command has not
all the feature it currently has is  interesting too.

Note with that kind of list I can automatically
generate a per-command diff of documentation using my private CMake
binary collection :-]
-- 
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] providing library information, what's the cmake way

2010-11-25 Thread Eric Noulard
2010/11/25 Marcel Loose :
>>
>> Everyone looks into his local CMake documentation and uses what he
> finds
>> in there. And then it breaks on older versions. You currently have
> no
>> chance to know what works but to install all older versions and do a
>> binary search in the documentation. That simply does not scale.
>>
>> Eike
>
> That's what CMAKE_MINIMUM_REQUIRED() is for. If you're developing with
> CMake 2.8.2, and you want to make sure that you don't use any features
> that are not supported by CMake prior to version 2.8.2, you should put
> this at the top of your CMakeLists.txt file:
>
> CMAKE_MINIMUM_REQUIRED(VERSION 2.8.2)

Unless I'm wrong this is NOT ensuring what you said.
This statement will make CMake shout at you if you try
to use CMake version less than the specified version:

"If the current version of CMake is lower than that required it will
   stop processing the project and report an error.  When a version
   higher than 2.4 is specified the command implicitly invokes

 cmake_policy(VERSION major[.minor[.patch]])

   which sets the cmake policy version level to the version specified.
   When version 2.4 or lower is given the command implicitly invokes"

so the "minimum" required version is checked and the corrresponding
policy is enforced.

BUT... this does NOT ensure that while requiring minimum 2.8.2 and
you are currently using 2.8.3 (or any later version) your 2.8.3 will behave
as if it was 2.8.2.

If a new CMake command and/or option for an existing command has been
added between 2.8.2 and 2.8.3 but is not subject to some policy then
if you use it you won't get a warning.

but you'll break your user using CMake 2.8.2.

I think that's why Dave said:

"If you want to support CMake 2.6.4 (or whatever previous version you
require, for whatever reason), then you should be using *that* version
for your local development, and have that be the
cmake_minimum_required version. And use that version to look up
documentation..."

> But you do have a point. It would really help people developing CMake
> files to know whether they can use a given command or not if they want
> to support, say, CMake 2.6.0.

Thus my proposal based on Tyler idea to attach a list of version
to each CMake command/variables/properties which contains
the first CMake version which included the feature
followed by the list of CMake version which modified the behavior/feature.

>  To be honest, the people at Kitware don't
> make that an easy job, because almost every patch-release contains new
> features :-(

May be they are too-responsive to user request :-]

-- 
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] providing library information, what's the cmake way

2010-11-26 Thread Eric Noulard
2010/11/25 Johannes Zarl :
> On Wednesday 24 November 2010 19:03:21 David Cole wrote:
>> On Wed, Nov 24, 2010 at 12:58 PM, Tyler Roscoe  wrote:
>> > On Wed, Nov 24, 2010 at 11:41:46AM -0500, David Cole wrote:
>> >> On Wed, Nov 24, 2010 at 11:34 AM, Rolf Eike Beer  wrote:
>> >> > So I think it is _really_ necessary to go through all the CMake
>> >> > documentation items and add a line about when which feature was added.
>> >>
>> >> Adding that information in the documentation would be good, I agree.
>> >> (Although quite time consuming and costly for somebody...)
>> >
>> > Perhaps a good compromise is simply to add version information to all
>> > new CMake commands/variables/properties that are added henceforth?
>> >
>> > Thanks,
>> > tyler
>>
>> That does sound like a good idea.
>
> From the information in http://www.cmake.org/Wiki/CMake_Released_Versions and
> using some shell-scripts to create the diffs between all "neighbor-versions",
> it's not too much work to create a compatibility matrix for the documented
> features.

May be it can be fully  automated suche that adding a column for each new
CMake release would take minimum time?

> I took the liberty and compiled such a compatibility matrix here:
> http://www.cmake.org/Wiki/CMake_Version_Compatibility_Matrix
>
> It's a draft and does not (yet) contain information about properties and
> variables, but if this idea receives general consent I could complete the
> information.
>
> What do you think? Is this worth the effort, or would no one ever bother to
> update the information?

I like it too, I think it's very handy.
Concerning the update I think I will be done (and I may help)
if some scripts pre-digest the informations to be laid out.

-- 
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] How to get the current date

2010-11-26 Thread Eric Noulard
2010/11/26  :
> Hello,
>
> Is it possible in a CMakeLists.txt file to get the current date (under linux 
> and windows) ?
> I would like to store this date in a cmake variable so as to write it in a .h 
> file.

CMake has no builtin for that but if you search the ML archive
http://www.cmake.org/Wiki/CMake_FAQ#Where_can_I_find_searchable_CMake_Mailing_Archives.3F
you'll find several discussions (and solution proposal) on this subject.
-- 
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] Forcing 'out-of-source' build

2010-11-26 Thread Eric Noulard
2010/11/26 Wylie, Brian :
> Hi All,
>
> I want to force an 'out-of-source' build for a small project that I converted 
> to use Cmake.
>
> I did a bit of searching and found variants of the following...
>
> # Make sure the build is out of source
> STRING(COMPARE EQUAL "${CMAKE_SOURCE_DIR}" "${CMAKE_BINARY_DIR}" insource)
>  IF(insource)
>    MESSAGE(FATAL_ERROR "Do not build in your source dir please :)")
>  ENDIF(insource)
>
>
> It works but it still generates a CMakeCache.txt file and a CMakeFiles 
> directory in the source directory (which I've also seen others discussing)... 
>  is there a more official way to block 'in-source' builds that leaves the 
> source dir pristine?

There is a feature request pending for this (with one duplicate)
http://www.vtk.org/Bug/view.php?id=6672

-- 
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] [cmake-developers] CMake bug tracker discussion

2010-12-09 Thread Eric Noulard
2010/12/9 David Cole :
> Hello CMake users and devs,
>
> (And now for something completely different...)
>
> Controversial questions:
>
> - Should we eliminate the bug tracker entirely and just do all
> discussion and patches on the mailing list? (Why have two sources of
> information...?)
>
> - Or, alternatively, should we eliminate the bulk of mailing list
> traffic, and insist on issues in the bug tracker being the main
> conversational forum for the whole community?

I would personally vote for keeping both.

I'd like to keep ML bug related activities for:
1) Having preliminary discussion like
 Is this a bug or not?
 If it is a feature request is it worth a formal request ...?

2) Public poll directed to people who seldom browse the bug tracker.

Then use the tracker:

 1) When we are sure (with or without discussion) that the issue
 is a bug or a feature request.

 2) Because one NEEDS to keep track of changes, bug fixes etc...

So my opinion is that BOTH are mandatory, including the usage
of the ML for bug handling but may be some "common usage rules may be
advertised".

Now I agree that may be the systematic handling of bugs filed into the tracker
has to be improved but I think it already started.

As external free-time contributor to CMake I was granted commit right when
CMake was using CVS, it's even more easy now with git since
I can autonomously commit patches to next branch
(see CMake workflow http://www.cmake.org/Wiki/CMake/Git)
which is regularly (once a week) merged to master by Kitware.

I do get (I don't remember since when) a copy of each new bug entered in the
tracker so that I can (autonomously) assign those bugs to myself if do think
I can handle it.

If I cannot (not enough time or not my expertise zone) but I'm interested in the
bug I do add myself to the monitor list and may add some personal
comments to the bug report.

So to comment to Pau remark:
> Maybe you could start by having some people from outside of Kitware
> (apart from Alex ;-) ) help with triaging bugs and commit patches and
> not-too-complex features.

I'll try to do that myself but I'm far away from Alex efficiency :-]

May be helping the bug triage would be nice, may be some people
may search the bug tracker  for "unassigned" and "oldish" bugs
and send some list of such bugs from time to time on the
cmake-developer ML?

I know that some Kitware people do that (searching the Bug Tracker)
from time to time but I do not know if it is systematic nor periodic :-)

May be opening a Wiki page with the list of CMake developers (Kitware
and outsiders)
with their domain of CMake expertise may help "triage volunteer" to contact them
about the "unassigned" and "oldish" bug?


-- 
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] CMake bug tracker discussion

2010-12-10 Thread Eric Noulard
2010/12/10 Bill Hoffman :
> There are a few things we have already started to do that should help with
> the bug tracker issue.
>
> 1. We hare having 4 releases of CMake each year.   After each release we
> post to the list and ask people to "vote" for bugs they would like fixed in
> the next release.
>
> 2. We are now sending all new bugs to the cmake-developer list.  This way
> any CMake developer can start working on them or at least know about them
> when the are opened.

This was a very good idea.

I would suggest that each reporter get the follow-up of the bug he posted,
I think (but I have no way to verify that) that bug reporters do not
get automatic
e-mail follow-up for each comment posted to their bug unless they add themselves
as "monitor".

I'm using this default behavior for other opens source project bug
tracker and I usually
get fast answers (including "I have no time/mean to answer") on bug comments.

Knowing that, If a bug reporter does not react to a comment posted on his bug I
would usually tend to stop working on this bug because of the lack of
info and let the bug
close itself after a grace period.

> I have a third idea that we have not yet tried:
>
> What do people think of automatically closing bugs if they are not modified
> for some period of time (say 6 months).   They can always be reopened if the
> closed.   By closing them, it will notify those that have expressed interest
> in the bug.  We could send the closed bugs to the cmake-developer list just
> like the new ones.  That way all developers will know that they are being
> closed.

I would prefer having 2 messages:
One after 6 monthes of inactivity (i.e. no new comments etc...)
   saying the bug will be automatically closed a month later
   unless the situation evolves
A second one closing it if no activity is seen after the "grace period".

Those message should be sent to the monitor list AND the bug reporter.

The first message should be didactic, and may be explain that a bug
is more easily fixed with the involvement of the reporter:
- test case
- patch
etc

-- 
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] Trying to setup make folder configuration on linux

2010-12-11 Thread Eric Noulard
2010/12/11 Louis Hoefler :
> Indeed, it works with
> INSTALL(PROGRAMS ${CMAKE_CURRENT_BINARY_DIR}/massmailer DESTINATION bin)

This is not the appropriate way to install a target build with cmake
(even if it works).
Like Tyler said you should be doing something wrong in your CMakeLists.txt.

>
> PS.: This is only a development computer, you do not want to know how ofter
> I accidently entered rm -f somewhere, and since I want to install into the
> global bin path, I need root access.

On Linux (and may be on other platforms too) you'd better be building
a package (DEB, RPM)
using CPack as "normal user" and
install the generated package as root.

This will even be easier to remove your installation without messing
up with "rm -rf".
The package manager (rpm, dpkg) may safely uninstall the package you
did install before.

-- 
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] INSTALL when source file is already at DESTINATION?

2010-12-15 Thread Eric Noulard
2010/12/16 Gregory Peele ARA/CFD :
> Hi all,
>
> What is the expected behavior is for INSTALL (TARGETS) when the source file
> for a particular destination is already at the relevant DESTINATION?  For
> example, this could happen with a  Unix Makefile generator for "LIBRARY
> DESTINATION lib" when CMAKE_INSTALL_PREFIX/lib and
> CMAKE_LIBRARY_OUTPUT_DIRECTORY are the same path - the latter having been
> set differently than the default of course.
>
> In practice it seems like this case works fine for all types of targets in
> Windows/MSVC generators, and fails only for shared objects in Linux/Unix
> Makefiles.  It might even only fail for shared objects with SOVERSION
> symlinks but I haven't confirmed that yet.    The actual shared library is
> being deleted at some point after build (leaving a dangling symlink) and
> then the INSTALL step fails because its source file is missing.

Would you have an example with file names?
For example I have some shared lib with so version and I get (in the build dir)*

(1) libCERTId.so -> libCERTId.so.3
(2) libCERTId.so.3 -> libCERTId.so.3.4.1cvs
(3) libCERTId.so.3.4.1cvs

then I get the same set of files and symlinks in the (separate) install tree.
Do you mean that in your case the plain file (3) is deleted ?

> Not a big deal for me since this only comes up in very controlled
> circumstances in my project that are handled by macros - I skip the TARGETS
> install step when this will happen.   I'm just curious if this failure is
> expected or could be considered a minor bug.

My point of view would be that this is a user mistake and the best CMake can do
would be  to warn about the collision and simply avoid "install onto
myself" case.

-- 
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] How to detect whether CMake scripts are executing under / within CPack environment?

2010-12-18 Thread Eric Noulard
2010/12/16 Andreas Mohr :
> Hi,
>
> [subject formulated for best keyword search impact]
>
> forgive me for the possibly dumb question,
> but since cpack of course includes executing the "make install" step
> I'd like to know how to possibly detect this within CMake code.
> My build is capable of launching an external script
> to pop up a "build complete" message, which then of course
> unhelpfully also occurs during cpack -G DEB (thus completely stopping the
> packaging due to non-parallel build execution in this environment),
> thus it would be useful to automatically turn it off in such cases.
> Of course a potential solution might actually turn out to be
> generator-specific (e.g. Makefile). :-P
> I'm afraid since CPack is likely executing a generated CMake
> environment, detection is difficult or even impossible.

This is an interesting question.
Currently I think you are right there is no *builtin* way to know if your script
is being run from within CPack.

I think the feature is interesting and it is worth a feature request.
The solution is easy: make CPack defines something like CPACK_IS_RUNNING
variable and then you can do

IF(CPACK_IS_RUNNING) from within your script.

Builtin support for this needs [very small] patch.

Now you can emulate this feature by using a CPACK_PROJECT_CONFIG_FILE.
See the doc here:
http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#Overall_usage_.28common_to_all_generators.29

The CPACK_PROJECT_CONFIG_FILE is loaded by CPack for each generator it
has to launch
so if you unconditionnally define

set(CPACK_IS_RUNNING 1)

in this file then CPACK_IS_RUNNING will be defined before your install
time script is runned.

I didn't tried but I think  it should work as expected.


-- 
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] Sign a deb file builded by cpack

2011-01-02 Thread Eric Noulard
2011/1/2 Paolo Zaffino :
> Dear all,
> first of all my best wishes at all for an happy new year.
> Do anyone know if there is a way to sign a deb package builded by cpack?
> Thank you very much.

As far as I know there is built-in support for signing deb in CPackDeb.
However using
dpkg-sig : http://packages.debian.org/search?keywords=dpkg-sig
or
debsigs: http://packages.debian.org/search?keywords=debsigs

Should work.

Note that I would happily review a patch which makes it easier
to sign deb package with some extra CPACK_DEBIAN_PACKAGE_xxx vars.

-- 
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] Sign a deb file builded by cpack

2011-01-03 Thread Eric Noulard
2011/1/3 Paolo Zaffino :
> Thank you Eric...I'll use dpkg-sig.
> Please let me know when the patch will be introduced.

To be more clear:

Adding this feature is not currently on my CMake TODO list.

My previous remark was an invitation for YOU (or anyone else)
to provide a patch. Then I'll be able to review it and may be merge it
for next CMake release :-]

To summarize, If you wan't the feature to be introduced in some future
CMake version:

1) Open a bug tracker entry for that explaining your motivation
2) Attach your patch to the tracker

2) is optional but a provided patch improves the chance to get the
feature inside CMake.

-- 
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] Delivery target

2011-01-05 Thread Eric Noulard
2011/1/5 Michael Wild :
> On 01/05/2011 02:13 PM, Reinhard Thies wrote:
>> On Wednesday 05 January 2011 12:32:52 David Cole wrote:
>>> You can't depend on "package", but you can do this as your custom
>>> target's command:
>>>
>>>   cmake --build . --target package --config Release
>>>   scp ...
>>>
>> that the way I have it
>> ADD_CUSTOM_TARGET(delivery
>>         rm -rf ${CMAKE_PROJECT_NAME}*.tar.gz
>>         COMMAND make package
>>         COMMAND scp ${CMAKE_PROJECT_NAME}*.tar.gz ds:/srv/repos/bin
>> )
>>
>> I just thought there might be a better way.
>>
>> thx,
>> Reinhard
>
> If you *know* that you *always*
>
> - have a POSIX shell
> - use a Makefile generator
> - have scp installed on host and target machine
>
> then things are fine, otherwise this will fail. If you used
[...]

I think I already said that some time ago, but this
is just a pity CMake "file" command does not support UPLOAD:

file(UPLOAD file url TIMEOUT timeout] [STATUS status] [LOG log])

the DOWNLOAD counter part is based on libcurl which supports scp
such that it would be possible to portably copy file using a CMake script.

If some of you think the feature is interesting I may file a feature request
and may be try a patch.


-- 
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] CPack tar ownership

2011-01-07 Thread Eric Noulard
2011/1/7 Tim St. Clair :
> Is there a way to make all entries in the tar package are owned by
> root, vs. build user.

On which platform?
Linux ? Debian? Fedora?

Did you try using "fakeroot"  ?


-- 
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] CPack tar ownership

2011-01-08 Thread Eric Noulard
2011/1/8 Tim St. Clair :
> This will be across several *nix platforms,
>
> I tried fakeroot but when I expand it has the euid of the user.

This is odd, by the way which version of CMake are you using?

On my ubuntu 10.04 box with CMake 2.8.3, I get:

A) cpack -G TGZ
leads to a tar+gz archive whose content its owned by the user.
(as printed out using 'tar ztvf file.tgz')

B) fakeroot cpack -G TGZ
leads to a tar+gz archive whose content its owned by root.
(as printed out using 'tar ztvf file.tgz')


An alternative solution would be to force ownership on extraction,
GNU tar has the option:
--no-same-owner
   extract files as yourself

which should do the job (I suppose you can be root when extracting).


Do you have any self contained example which exhibits the problem?

-- 
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] TARGET_LINK_LIBRARIES not working for MSVC

2011-01-08 Thread Eric Noulard
2011/1/8 Avanindra Singh :
> Hi all,
> I have been trying to build a project under MSVC which I generated through
> CMAKE. The same projects compiles correctly  without any error in UBUNTU.
> But
> when I build the same project under msvc, I get so many linking errors. From
> the project configuration of msvc project I figured it out that none of
> libraries are linked.
> The project configuration does not contain linker tab, but rather a
> Librarian tab comes which does not contain any of the linked libraries which
> I put in TARGET_LINK_LIBRARIES.
> I am relatively new to cmake. Please point out where I am making mistake.
> I would put here the root CMakeLists.txt and one subdirectory ./lib/imagelib
>  CMakeLists.txt
> cmake_minimum_required(VERSION 2.4)

This is very old version of CMake.
Are you sure you are not able to at least require 2.6 (if not 2.8)
I understand you are beginning with CMake so this historical
requirement may not be necessary.
(Unless you know that some of your user must use CMake 2.4)

> if(UNIX)
> PROJECT(hybridnccsurfacecoloring C CXX Fortran)
> endif(UNIX)
> if(WIN32)
> PROJECT(hybridnccsurfacecoloring C CXX)
> endif(WIN32)

I would do:
PROJECT(hybridnccsurfacecoloring C CXX)

if(UNIX)
   enable_language(Fortran)
endif(UNIX)

>
> ADD_DEFINITIONS(-DNO_BLAS_WRAP)
>
> SET(OpenCV_DIR "E:/opencv-devel/opencv/release2")
> #SET(BOOST_ROOT "C:/Program Files/boost/boost_1_45_0")
> #set (Boost_DEBUG ON)
> find_package(OpenCV)
> find_package(ImageMagick COMPONENTS Magick++ MagickCore)
> #find_package(Boost 1.45.0 COMPONENTS filesystem)
>
> if(OpenCV_FOUND)
> message(STATUS "Opencv found.")
> include_directories(${OpenCV_INCLUDE_DIRS})
> link_libraries(${OpenCV_LIBS})

link_libraries is "Deprecated." you should use "target_link_libraries" on each
target instead.

[...]

> link_libraries(${ImageMagick_LIBRARIES})

same here
[...]

> link_libraries(
>
>  "C:/downloads/ImageMagick-6.6.2/VisualMagick/lib/IM_MOD_DB_magick_.lib"
>
>  "C:/downloads/ImageMagick-6.6.2/VisualMagick/lib/CORE_DB_magick_.lib"
>      "C:/Program
> Files/boost/boost_1_45_0/stage/lib/libboost_filesystem-vc90-mt-gd-1_45.lib"
>               )

same here

[...]


-- 
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] Fwd: TARGET_LINK_LIBRARIES not working for MSVC

2011-01-08 Thread Eric Noulard
> Hi john,
>
> Thanks for the reply.Multiple TARGET_LINK_LIBRARIES
>  did not give any configuration error. Though I removed the WIN32 If
> block, but I am still getting the same linking errors.
> TARGET_LINK_LIBRARIES(hybridnccsurfacecoloring bundler imagelib matrix mathlib
>                       5point libsba  libepnp
>                       sfm libDescriptors f2c  minpack lapack ann getopt jpeg)
> #if(WIN32)
> #TARGET_LINK_LIBRARIES(hybridnccsurfacecoloring getopt jpeg)
> #endif(WIN32)
> I am absolutely clueless why the linker is not generated in the msvc
> project. Any idea what could be the possible reason for it?...

May be you can a try a simpler executable target which only requires
one lib then try this example both on Linux and MSVC.

The idea is, scale down your problem to something more easy to
understand for us.
In the current case we don't know if ALL your target are failing to
link or some of them
which symbols are missing etc...

Which version of CMake are you using (On Linux and on Windows)?
Did you try with Code::Blocks  on windows?

Are the find_package statement successful on Windows too?
e.g. does;
find_package(ImageMagick COMPONENTS Magick++ MagickCore)
leads to ImageMagick_FOUND or not?

-- 
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] Fwd: TARGET_LINK_LIBRARIES not working for MSVC

2011-01-08 Thread Eric Noulard
2011/1/8 Avanindra Singh :
> Hi Eric,
> Thanks for the reply. It was very useful. I incorporated the changes you
> mentioned. I removed all the link_libraries macros
> from the projects. Also I changed camke_minimum_version to 2.6 . I have
> CMake 2.8 in both windows as well as Linux. Though
> I am still getting the same errors.I would strip the project down to one or
> two lib and I would get back with the results.
> Though one point I would like to mention, the linker problem is coming for
> all the libraries in project added through
> ADD_LIBRARY macro.

Do you handle the visibility of symbols in libraries properly?
On Linux the [usual] default is to have all symbol exported whereas
it's the converse on Windows (no symbol exported unless specified).

You have to use
__declspec(dllexport)
__declspec(dllimport)
statement in the Windows case.

See:
http://www.cmake.org/Wiki/BuildingWinDLL

-- 
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] module contribution?

2011-01-09 Thread Eric Noulard
2011/1/9 Nico Schlömer :
> Quick question here:
>
> I have a couple of libraries here which all need NetCDF, so I was
> thinking the cleanest solution would be to write one FindNetCDF.cmake
> and use it everywhere. What's the policy of including modules into the
> official CMake branch?

http://www.cmake.org/Wiki/CMake:Module_Maintainers




-- 
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] CPack and configure_file

2011-01-10 Thread Eric Noulard
2011/1/10 Tobias Ellinghaus :
> Hello,
>
> I create some files inside of CMAKE_CURRENT_BINARY_DIR using configure_file().
> These are not installed but needed for compiling the program. When creating a
> .tgz file with make package_source these files are not included so that the

package_source will include all file inside CMAKE_SOURCE_DIR
so if you are doing out-of-source build the observed behavior is the
expected one.

> resulting source package is basically useless.

WHY do you think so ?
WHY you want to put GENERATED file inside your source .tgz?
Do you expect your user to build from source without CMake?

> Is there a way to add these files? I have searched through google and the list
> archives and only found http://www.cmake.org/Bug/view.php?id=8438

I cannot see the relationship between your issue and the refered bug?

> which would at least allow to copy the files into CMAKE_CURRENT_SOURCE_DIR.

You may generate those file (with configure_file) inside your source tree
and the generated file will be packaged by "package_source", but again
WHY do you want to include a generated file inside your source package?


-- 
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] cmake and buildvariants

2011-01-10 Thread Eric Noulard
2011/1/10 John Beuving :
>
> I have the following software setup where I need to have build variants
> providing different builds for the same (sub)project
>
> -    worker ( calls the Qt Processevents function if Qt is enabled for this
> project (#define  USE_WORKER_QT)
> -    gui app (uses Qt)
> -    console app (normal application used for data export)
>
>
> So the gui application uses Qt and needs to use the worker static library
> with the define USE_WORKER_QT set
> and the console application needs a variant build of the worker library
> where USE_WORKER_QT is not set.
>
> How can I achieve this. Is this even possible with cmake ??

You may build your worker lib twice:

# first build USE_WORKER_QT is not set
add_library(worker-noqt STATIC ${WORKER_SRC})

# second build USE_WORKER_QT set
add_library(worker-qt STATIC ${WORKER_SRC})
set_target_properties(worker-qt PROPERTIES COMPILE_FLAGS "-DUSE_WORKER_QT")

#link the apps with the appropriate build of the worker lib

add_executable(gui-app ${GUI_SRC})
target_link_libraries(gui-app worker-qt)

add_executable(console-app ${CONSOLE_SRC})
target_link_libraries(console-app worker-noqt)

-- 
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] FIND_PROGRAM w/ CMake 2.8.2 and Cygwin

2011-01-10 Thread Eric Noulard
2011/1/10 marco atzeri :
> On Mon, Jan 10, 2011 at 3:43 PM, Emmanuel Blot  wrote:
>> Hello All,
[...]
>>
>> 1/ Is this a known issue / new regression?
>>  I have not been subscribed to the ML for a while, and I can't find a
>> decent way to search through the ML archives,
>> http://www.cmake.org/pipermail/cmake/ does not offer a search
>
> use gmane for the search
> http://news.gmane.org/gmane.comp.programming.tools.cmake.user

or read the FAQ topic on this subject:
http://www.cmake.org/Wiki/CMake_FAQ#Where_can_I_find_searchable_CMake_Mailing_Archives.3F

-- 
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] CPack and configure_file

2011-01-11 Thread Eric Noulard
2011/1/11 Tobias Ellinghaus :
> Am Montag, 10. Januar 2011 schrub Eric Noulard:
>
>> > which would at least allow to copy the files into
>> > CMAKE_CURRENT_SOURCE_DIR.
>>
>> You may generate those file (with configure_file) inside your source tree
>> and the generated file will be packaged by "package_source", but again
>> WHY do you want to include a generated file inside your source package?
>
> Because some information (like latest git commit as version string) is no
> longer available when using a source package. Of course I can put the
> generated files into the source tree, but that's kind of against the idea of
> out-of-source builds.

Ok I understand but your source package is meant to be built with
CMake too right?
So you have to handle the case "Am I" building from git source tree or from
"package source" tree from within your CMakeLists.txt ?

So you can perfectly add something like:

supposed GIT_TREE is true if your are configuring a git tree:

if (GIT_TREE)
   configure_file(whatever.h.in ${CMAKE_CURRENT_BINARY_DIR}/whatever.h)
   configure_file(whatever.h.in ${CMAKE_CURRENT_SOURCE_DIR}/whatever.h.srctree)
else(GIT_TREE)
   configure_file(whatever.h.srctree
${CMAKE_CURRENT_BINARY_DIR}/whatever.h @COPYONLY)
endif(GIT_TREE)

the "whatever.h.srctree" is your generated file that will be package
with your source tree
but it will only be used if you are building from a non GIT source tree.

and... you can do out-of-source build in both cases.

concerning the fact that:
> Of course I can put the
> generated files into the source tree, but that's kind of against the idea of
> out-of-source builds.

That's true but in any case you want your source package to contain the file
so the file WILL end up in the source tree when building from package
source right ?

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


<    1   2   3   4   5   6   7   8   9   10   >