Re: [CMake] SET_SOURCE_FILES_PROPERTIES different properties for same file, same library

[Eric Noulard]

2010/5/12 Michael Wild :
>
> On 12. May, 2010, at 13:03 , Bryn Lloyd wrote:
>
>> Hi,
>>
>> I would like to cmakeify the UMFPACK/AMD libraries by Timothy Davis.
>>
>> I need to compile the same source file, multiple times, with different 
>> flags/defines in order to link the resulting object files into one library.

Looks like an "already crossed" question on the ML:

http://www.cmake.org/pipermail/cmake/2009-December/033813.html

[...]
>
> No need to copy, just CONFIGURE_FILE a wrapper into the build tree which 
> includes the source file. Sure, will give you a little overhead but that's 
> probably negligible.

With hopefully very similar answer :-)


-- 
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 does CPACK decide what goes into release packages?

[Eric Noulard]

2010/5/17 Tyler Roscoe :
> On Mon, May 17, 2010 at 12:53:34PM -0500, kent williams wrote:
>> "Internally, CPack will use CMake's install mechanism to automatically
>> populate the package."
>
> Right. Mostly, all that CPack does is call "make install" on your
> project with a special CMAKE_INSTALL_PREFIX.
>
>> but when I add
>> include(CPack)
>> and then run
>> make package
>>
>> It generates empty install packages.

I'll add a bunch of questions:

1) Which platform (Unix, Windows, MacOs etc...)
2) What is the cpack/cmake version  (output of cpack --version)
3) Which CPack generator are you using (ZIP, TGZ, DEB, NSIS, PackageMaker,...)

>> The only target (for now) that needs to go into the package is a
>> single statically linked executable, which is referenced with a cmake
>> install command:
>>
>> INSTALL(TARGETS BRAINSFit DESTINATION bin)
>
> What does your project do when you "make install"?
>
> tyler

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

[Eric Noulard]

2010/5/18 R. Bryn Fenwick :
> Hi,
>
> I have received some code that works on one system, but is failing to work
> for me. Any suggestions how to debug this would be greatly appreciated.
>
> I think that I am setting everything up correctly however it appears to need
> some hacks.

[...]

> ../libscimap.a(densematrix.cpp.o): In function
> `DenseMatrix::largest_eigenvectors(int&, DenseMatrix&, double*, int*)':
> densematrix.cpp:(.text+0x3784): undefined reference to `dgemv_'
> densematrix.cpp:(.text+0x3849): undefined reference to `dgemv_'
> densematrix.cpp:(.text+0x3a6a): undefined reference to `dgemm_'
> ../../../ARPACK/libparpack.a(pdseupd.o): In function `pdseupd_':
> pdseupd.f:(.text+0x70c): undefined reference to `dcopy_'
>
> many more similar errors follow including these for lapack itself...
>
> /home/fenwick/opt/lapack-3.2.1/SRC/dlarfg.f:116: undefined reference to
> `dnrm2_'
> /home/fenwick/opt/lapack-3.2.1/SRC/dlarfg.f:120: undefined reference to
> `dscal_'

[...]

All missing symbols are "BLAS" library symbols, so why [see below]

> I am trying to use lapack though in the CmakeLists file there is no mention
> of a fortran compiler
>
> project(SCIMAP CXX C)
> cmake_minimum_required(VERSION 2.6)
[...]

...why did you comment out the find_package(BLAS   REQUIRED) ?

This question may be silly because LAPACK already depends on BLAS
so I guess find_package(LAPACK) will look for BLAS too...


> find_package(LAPACK REQUIRED)
> #find_package(BLAS   REQUIRED)
> find_package(ARPACK REQUIRED)
> include_directories(${ZLIB_INCLUDE_DIR} ${MPI_INCLUDE_PATH})
> add_definitions(${MPI_COMPILE_FLAGS})
> set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} ${MPI_LINK_FLAGS}")
> set(CMAKE_MODULE_LINKER_FLAGS "${CMAKE_MODULE_LINKER_FLAGS}
> ${MPI_LINK_FLAGS}")
>
> add_subdirectory(src)

Concerning the Fortran language thing may be its enabled somewhere in Find.
I saw you asked for cmake_minimum_required(VERSION 2.6)
may you shoudl even cmake_minimum_required(VERSION 2.8)
because I think CMake 2.8.x solves issues with Fortran/C integration with CMake,
I'm not a specialist here so may be you should search the ML archive for Fortran
related topics.

-- 
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] newbie question - what targets are supported?

[Eric Noulard]

2010/5/28 Michael Hertling :
> On 05/28/2010 12:14 AM, Doug Reiland wrote:
>> okay, I have ordered the book. But, in the meantime.
>>
>> I am continuing to port a large library from in-house build to cmake
>> for evaluation.
>> What builtin targets are supported?
>
> On *nix, run CMake on a directory with an empty CMakeLists.txt, then
> invoke "make help" and you'll see the targets provided a priori - or
> did you rather mean "rules" instead of "targets"?
>
>> I got lex, gperf, and other kinds of stuff.

As a complement, many "things" are supported using custom CMake modules:

cmake --help-module-list

will give you a list of CMake modules shipped with CMake, while

cmake --help-module 

will give you more detailed information about the module.
For example:
cmake --help-module FindFLEX

may be worth reading if you are using lex.

-- 
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] Generator for NetBeans 6.9

[Eric Noulard]

2010/5/31 Sebastian Meier :
> Update.
>
> My allocated time slot for looking into a NetBeans generator has finished. My 
> impression is that patching CMake to suit our company's needs would be fairly 
> easy. I have actually gotten quite far with that.
>
> But OTOH this easy way would be merely a hack that would benefit no one but 
> us. I will recommend a more general approach that would be of use to other 
> people as well and hope I'll get some more time for that.

May be you can share the hack as a patch on the bug tracker.
May be it's unusable as-is but it may already contain valuable
information for anyone wanting
to tale over?

> P.S.: I have still not entirely grasped how to properly respond to e-mails on 
> this mailing list so that they appear in the right place. Please excuse me 
> for this. I guess I'm more used to forums etc.

Reply-to-all then strip eventual list of individuals which gets cc
along the ML thread.
-- 
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] Generator for NetBeans 6.9

[Eric Noulard]

2010/5/31 Sebastian Meier :
> Hi Bill,
>
>> Can NetBeans be driven from the command line?  That is a requirement for
>> getting try_compile to work.
>
> No, I don't think it is possible call NetBeans via command line in order to 
> build targets. But since NetBeans relies on external tool chains like gcc, 
> MinGW  or CygWin, is this really necessary?

CMake includes TRY_COMPILE feature for which will create an
appropriate CMake project
in order to try compile...
Thus CMake will use CMAKE_BUILD_TOOL in order to try to build, since
you said you won't
go for "Makefile-based" generator there should be a way to "build"
with NetBeans.

More informations:
cmake --help-variable CMAKE_BUILD_TOOL
cmake --help-variable CMAKE_GENERATOR
cmake --help-variable CMAKE_EXTRA_GENERATOR

-- 
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] Project initialization file path

[Eric Noulard]

2010/6/9 Aby Louw :
> Hi,
>
> I have a Linux project that reads an initialization file on startup to
> get some file names and variables.
>
> When doing an in-source or out of source build, I generate the
> initialization file in the CMAKE_BINARY_DIR and then also generate the C
> file that reads this file so that I know the correct path.
>
> Now when doing a "make install" I want to install the initialization
> file on the /etc path. Therefore the initialization file path in the C
> file needs to be updated. However I do not know how to recompile the C
> target before installation happens.

Looks odd to bury some config into a compiled C-file.
If the C file contains some "actual installation path" It may be easier for this
executable/function to lookup **at runtime** its actual install path...

If this C file is "reading" some config file may be you can add
some primitive search path mechanism,

 1) look in "."
 2) look in "${CMAKE_INSTALL_PREFIX}/" --> you must be doing
something like that now
 3) use some environment var prefix
  getenv(HOME)/... --> using HOME env var
  getenv(MYSW_PATH)/ --> using specific env var

then during devel you may setup MYSW_PATH as you want
and then when installed ${CMAKE_INSTALL_PREFIX}/ will be used
provided 3) as a higher priority than 2)

> I need something like a pre install or, add_dependency to install
> target, but as far as I know this is not possible. Does anybody know of
> a workaround to this problem?

install(CODE  ...
or
install(SCRIPT ...

may help you to execute extra CMake action at install time.
However I would rather use some "search path" mechanism.

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

[Eric Noulard]

2010/6/9 Vincent LEFORT :
> Hello, i want to use CPack to generate my installer instead of NSIS
> directly.
> Is it possible to have translation of my installer using CPack/CMake ?

Automatic translation I don't think there exists some tools for that.
However CPack NSIS generator is using a template NSIS config file:

/share/cmake-x/.yModules/NSIS.template.in

If you put in your project your own NSIS.template.in file (adapted from
your current NSIS config file) and then modify you  CMake module path

this has already been done successfully:

http://www.mail-archive.com/cmake@cmake.org/msg13128.html

> For example : At the beginning, NSIS will ask the language of the installer
> and after, all the text will be in the selected language.
> I don't find anything about this subject and though it's possible with NSIS.

Diving into /Searching the ML archive may give you more information
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] change where package is generated; full name of package with extension

[Eric Noulard]

2010/6/18 Tyler Roscoe :
> 1. I want to change where "make package" deposits the packages it
> creates.  Is there a way to do this -- some cpack variable I haven't
> found?

No variable I am aware of.
However you may create a custom target which call make package and then
move the file, provided you know the name of the generated file 

>
> 2. I want to get a hold of the name (or names) of generated packages. I
> know the package will be called myproject.some_extension,

The name of the package file is
CPACK_PACKAGE_FILE_NAME+ extension.

If your CMakeLists.txt does not define CPACK_PACKAGE_FILE_NAME
then CPack will define it as:
${CPACK_PACKAGE_NAME}-${CPACK_PACKAGE_VERSION}-${CPACK_SYSTEM_NAME}"

again if CPACK_PACKAGE_NAME is not defined
it is defined by CPack as PROJECT_NAME.
if you want to know more about "default" for unspecified values
I suggest you dive into CPack.cmake file.

> but how do I calculate "some_extension"? Is there some mapping between 
> package type
> (TGZ, ZIP, NSIS) and the extension it ends up with (.tar.gz, .zip,
> .exe)?

Concerning the extension, it is  fixed in the C++ code of the generator
in the GetOutputExtension method:

cmCPackDebGenerator.h:  virtual const char* GetOutputExtension() {
return ".deb"; }
cmCPackGenerator.h:  virtual const char* GetOutputExtension() { return
".cpack"; }
cmCPackNSISGenerator.h:  virtual const char* GetOutputExtension() {
return ".exe"; }
cmCPackOSXX11Generator.h:  virtual const char* GetOutputExtension() {
return ".dmg"; }
cmCPackPackageMakerGenerator.h:  virtual const char*
GetOutputExtension() { return ".dmg"; }
cmCPackRPMGenerator.h:  virtual const char* GetOutputExtension() {
return ".rpm"; }
cmCPackSTGZGenerator.h:  virtual const char* GetOutputExtension() {
return ".sh"; }
cmCPackTarBZip2Generator.h:  virtual const char* GetOutputExtension()
{ return ".tar.bz2"; }
cmCPackTarCompressGenerator.h:  virtual const char*
GetOutputExtension() { return ".tar.Z"; }
cmCPackTGZGenerator.h:  virtual const char* GetOutputExtension() {
return ".tar.gz"; }
cmCPackZIPGenerator.h:  virtual const char* GetOutputExtension() {
return ".zip"; }

+ some other defined in .cxx files.

Note that currently every CPack generator only generates a single file
per project
but it may change depending of the issue of some open bugs:
see for example:
http://public.kitware.com/Bug/view.php?id=10736
and related bugs.


-- 
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] change where package is generated; full name of package with extension

[Eric Noulard]

2010/6/18 Tyler Roscoe :
> On Fri, Jun 18, 2010 at 06:30:25PM +0200, Eric Noulard wrote:
>> 2010/6/18 Tyler Roscoe :
>> > 1. I want to change where "make package" deposits the packages it
>> > creates.  Is there a way to do this -- some cpack variable I haven't
>> > found?
>>
>> No variable I am aware of.
>> However you may create a custom target which call make package and then
>> move the file, provided you know the name of the generated file 
>
> The frustrating part here is that I can't add_dependencies or post-build
> custom_commands to the PACKAGE target because it is a "magic" CMake
> target. I suppose I can look into writing a custom_command that runs
> cpack with appropriate arguments, but I hoped to avoid this step.

Or you can propose a patch for this long-running feature request
http://public.kitware.com/Bug/view.php?id=8438

 :-)

>> > but how do I calculate "some_extension"? Is there some mapping between 
>> > package type
>> > (TGZ, ZIP, NSIS) and the extension it ends up with (.tar.gz, .zip,
>> > .exe)?
>>
>> Concerning the extension, it is  fixed in the C++ code of the generator
>> in the GetOutputExtension method:
>
> Yeah, I was afraid of this. Looks like I'll need to maintain my own
> mapping of cpack generator types -> extensions on disk.

... or propose a patch for CPack which builds this map while running for 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] Non-build output

[Eric Noulard]

2010/6/20 Clark Gaebel :
> How would I go about placing a text file in the same directory as a
> target's output?
>
> For example, let's say I have a target called "foo", which creates an
> executable. "foo" has a config file called "foo.conf" that should always
> go in the same directory. At the moment, it resides in the src/
> directory for the "foo" target. How would I get it to automatically copy
> into the same directory as the foo executable as part of the build process?
>
> For bonus points, how would this interact with "make install"?

Concerning install:

Your target foo may be installed with
install(TARGETS foo DESTINATION where/you/want)

Your config file with
install(FILE foo.conf DESTINATION where/you/want)

Now if you want to put the foo.conf near to foo **in the build tree**
**and assuming foo.conf is in the same source dir as foo sources**
you may do:
configure_file(foo.conf foo.conf COPYONLY)

this should copy foo.conf from source tree to binary tree.
It may be a problem if you usually do in-source build so you may
a) rename foo.conf to foo.conf.in in the source
b) do
   configure_file(foo.conf.in foo.conf COPYONLY)


-- 
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] Link order of object files

[Eric Noulard]

2010/6/22 Mathias Lafeldt :
> Alexander Neundorf wrote:
>> On Monday 21 June 2010, Mathias Lafeldt wrote:
>>> Hi,
>>>
>>> is there a way to tell CMake in which order to link in object files?
>>>
>>> For example, I got the following executable:
>>>
>>>      ADD_EXECUTABLE(hello crt0.o hello.c)
>>>
>>> Using a disassembler, I can see that hello.c is compiled in before
>>> crt0.o, but I want crt0.o to always be the first.
>>>
>>> Also, this gives me the same result:
>>>
>>>      ADD_EXECUTABLE(hello hello.c crt0.o)
>>
>> Is this for some embedded system ?
>
> It's for the MIPS R5900 processor aka Emotion Engine.
>
>> You may consider putting crt0.o in the CMAKE_C_LINK_EXECUTABLE variable for
>> your target.
>
> Thank you. I didn't know about CMAKE_C_LINK_EXECUTABLE, but it seems to
> be suitable.

You may have a list of usable variables using command line:
cmake --help-variable-list

Normally you could have detail about one particular variable with:

cmake --help-variable THE_VAR

but

cmake --help-variable CMAKE_C_LINK_EXECUTABLE says:
Argument "CMAKE_C_LINK_EXECUTABLE" to --help-variable is not a defined variable.

cmake --help-variable CMAKE_\_LINK_EXECUTABLE
Argument "CMAKE_C_LINK_EXECUTABLE" to --help-variable is not a defined variable.



-- 
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] Searching the mailing list archives

[Eric Noulard]

2010/6/22 Bo Thorsen :
>
> The site: tells google to only consider URLs that contain this. I also use
> this to search for something in another country - site:co.uk if I want
> something in Great Brittain. (Yes, I know some there also has other domains,
> but for some searches that's not a problem).
>
>>
>> 
>
> I think my answer here could be appended to that list of options.

I think the google "site:" way is already there in the FAQ however
if you find something  could be enhanced
feel free  to update the  Wiki page yourself to put more precise informations.
-- 
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 (RPM) and install()

[Eric Noulard]

2010/6/23 Magnus Therning :
> The documentation for install() is clear, an absolute path (e.g.
> '/usr/lib') is used directly and relative path (e.g. 'lib') is
> prefixed by CMAKE_INSTALL_PREFIX.  Another thing to note is that 'make
> DESTDIR=foo install' *always* works as expected!
>
> However, the relation between install() and CPack is unclear
>
> - For some files I accidentally had an absolute install path, and
> during 'make package' these files got installed in the file system and
> they were left out of the RPM.  I naively assumed that the RPM builder
> would use DESTDIR to control where things end up, but I must be wrong.
>  Is this a bug?

Yes and no.
CPack RPM generator is not different than other generator
it uses DESTDIR iff CPACK_SET_DESTDIR is set to ON.

i.e.
SET(CPACK_SET_DESTDIR ON)

if you want CPack to use DESTDIR.

There is a bug report about that:
http://public.kitware.com/Bug/view.php?id=7000

> - The variable CMAKE_INSTALL_PREFIX is not used at all during RPM
> building.  CMAKE_INSTALL_PREFIX is /usr/local, but files get put into
> /usr in the RPM.  Is this a bug?

It should be using it.
Which version of CMake/CPack are you using.

Could you try:
cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -G RPM

and send me the output?

More infos on how to control CPackRPM with CPACK_RPM_xxx vars:
http://www.itk.org/Wiki/CMake:CPackPackageGenerators#RPM_.28Unix_Only.29
or
cmake --help-module CPackRPM

-- 
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 (RPM) and install()

[Eric Noulard]

2010/6/23 Magnus Therning :
> On Wed, Jun 23, 2010 at 15:41, Eric Noulard  wrote:
>> 2010/6/23 Magnus Therning :
> [...]
>>> - The variable CMAKE_INSTALL_PREFIX is not used at all during RPM
>>> building.  CMAKE_INSTALL_PREFIX is /usr/local, but files get put into
>>> /usr in the RPM.  Is this a bug?
>>
>> It should be using it.

My mistake.
You should define: CPACK_PACKAGING_INSTALL_PREFIX for defining your
"packaging" prefix.

This must be true for all CPack generator.

We "may" set CPACK_PACKAGING_INSTALL_PREFIX to "CMAKE_INSTALL_PREFIX"
but this would break backward compatibility...

CPack generators (including CPackRPM)  were used to provided their
**own** default value
for "CPACK_PACKAGING_INSTALL_PREFIX".

For RPM it is "/usr".


>
> Here's an example of what I mean:
>
>  bash-3.2# cmake ..
>  -- Found OCAML: 3.11.0
>  -- prefix: /usr/local
>  -- Configuring done
>  -- Generating done
>  -- Build files have been written to: /myrepos/ocaml-libs.hg/_build
[...]

>  bash-3.2# make package > /dev/null
>  bash-3.2# rpm -ql -p ocaml-libs-0.0.0-Linux.rpm
>  /usr
>  /usr/lib
>  /usr/lib/ocaml
>  /usr/lib/ocaml/ocamltest
>  /usr/lib/ocaml/ocamltest/META
>  /usr/lib/ocaml/ocamltest/ocamltest.a
>  /usr/lib/ocaml/ocamltest/ocamltest.cma
>  /usr/lib/ocaml/ocamltest/ocamltest.cmi
>  /usr/lib/ocaml/ocamltest/ocamltest.cmxa
>  /usr/lib/ocaml/ocamltest/ocamltest.ml
>  /usr/lib/ocaml/ocamltest/ocamltest.mli


> I'll take a look at this since I need to fix what's included in the source RPM
> next :-)

Patch are always welcome (but in this case It may not be acceptable
because it would break backward compatibility for a problem which
already have a solution)

If you do want to provide some patch please open a bug tracker entry
and attach your patch
to the tracker and/or provide some git repo containing your proposal
and indicate its url
in the tracker.  I.e. always open tracker entry for a patch proposal.
-- 
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] customize cpack windows installer

[Eric Noulard]

2010/6/25 Bo Thorsen :
> Den 23-06-2010 23:39, Alexandre Gramfort skrev:
>>
>> I'm deploying a cmake project on windows and I have a few questions
>> concerning the
>> installer generated by cpack using NSIS
>>
>> - is it possible to remove the mention "create desktop icon" since the
>> installer contains only command line tools?
>>
>> - is it possible to provide an installer that works even if the user
>> does not have admin rights?
>>
>> - is it possible to add to the folder in the start menu a link that
>> points to the web site of the project?
>
> Hi Alexandre,
>
> I recently started using CPack for the MariaDB installer, and it's been a
> kind-of bumpy ride so far.
>
> First of all, it's incredibly easy to build a simple installer with CPack
> and NSIS. But as soon as you step beyond the glorified zip file structure,
> it starts getting really hairy.
>
> I can't answer any of your questions, because I haven't tried to do those
> things. But I can tell you what I do when I try to find solutions to
> problems:
>
> 1) Search the net
> 2) Ask questions on the mailing list. One question per mail only! This looks
> like it gives the best answers, when answers are given.
> 3) Read the file ...\CMake 2.8\share\cmake-2.8\Modules\NSIS.template.in to
> try and figure out what happens and what you can or can't do.

Many questions about CPack + NSIS have been raised on teh ML,
many answers have been givent too. But it may be sparsy because some
"looking familiar" questions are being asked again.

May be some if not all CPack + NSIS users may start to improve the Wiki
with their CPack + NSIS experience?

Basic CPack may be put here
http://www.itk.org/Wiki/CMake:CPackConfiguration

NSIS Specifics may be put there:
http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#NSIS

Or may be we should start a "One page per generator"?


-- 
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] An observation about CTest

[Eric Noulard]

2010/6/27 Convey, Christian J CIV NUWC NWPT :
> I don't expect a lot of support for what I'm about to say, but I think it's 
> perhaps worth saying anyway...
>
> It seems like CMake's and CTest's have outgrown their scripting languages.
>
> As far as I can tell, all CMake/CTest variables are either macro formal 
> parameters, or variables in a
> single global namespace.  I think one consequence of this is that macro 
> invocations make their
> contributions primarily by modifying variables in the global namespace.  As 
> people discovered in the
> 1970's and 1980's, the confusion caused by this approach (global variables) 
> can be so extensive that
> it's worthwhile to change coding pracices (structured programming, etc.), and 
> possibly to improve
> the base language as well.

I think you should dive into the Mailing List archive because there
have been several valuable
discussion about CMake evolution including the "replacement/extension"
of CMake scripting
language with "full language" like Lua or Python.

> But even better would be enhancing the CMake scripting language to support 
> local variables in
> macros, and possible package-scoped variables as well.  This clarifies the 
> intended interface that
> certain macro packages are intended to provide, because variables intended as 
> implementation
> details would be in a namespace inaccessible to the script that invokes those 
> macros.

CMake is offering scope from a parent/child point of view including
setting variable for your parent with set( PARENT_SCOPE) this was indeed
provided after lengthly ML discussion.

Concerning "local variables" you should have a look at the difference between
a "MACRO" and a "FUNCTION" this may already gives you part of what you want.

Then as far as I can tell CMake scripting is no-where near a "must not
evolve" language
many improvement has been put in since I began to use CMake 2.2.x
(can't remember X)
even the introduction of "POLICY" which each backward compatibility.

So I think you may not hope to have ALL what you require in CMake
after a message on this
ML be you will certainly have feedback and may be new feature if there
is a consensus
and some proof of concept patch provided.

-- 
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] Preserve tree structur for IDEs

[Eric Noulard]

2010/7/1 Diablo 666 :
> Hi,
>
> I need CMake to create a Visual Studio solution for a project with several
> subdirectories but only one single library.
> How can I achieve project files that preserve this tree structure?

For "grouping" source in Visual Studio you may use

source_group(name [REGULAR_EXPRESSION regex] [FILES src1 src2 ...])

concerning "several subdir" for one lib, you may have a single CMakeLists.txt
the parent subdir which add_library from subdirs.
Say you tree is :

parent/subdir1
   /subdir2


the parent/CMakeLists.txt may contains

set(SRC_DIR1 subdir1/blah.cc subdir1/bouh.cc)
set(SRC_DIR2 subdir2/how.cc subdir2/how.hh)

add_library(whatever ${SRC_DIR1} ${SRC_DIR2})

You may add source group too:

source_group(LookHere\\SDIR1 FILES ${SRC_DIR1})
source_group(LookHere\\SDIR2 FILES ${SRC_DIR2})


-- 
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 (RPM) and install()

[Eric Noulard]

2010/6/23 David Cole :
> Well known issue for quite some time now.
> See the quite extensive notes in this bug:
> http://public.kitware.com/Bug/view.php?id=7000
> You can set CPACK_SET_DESTDIR to ON in your CMakeLists.txt file to get this
> to work with the RPM CPack generator.
> It would be fabulous if there were a way to fix this once and for all to
> everyone's satisfaction. However, it's tricky, because there are many
> different variables involved: the interactions among which are not always
> immediately obvious. If somebody has a brilliant patch that can fix that
> issue without breaking existing projects' use cases of CPack, feel free to
> attach it to the bug and let me know

I did attach a new one which would enable precise warning.

Fixing this for good was out-of-scope this time, but I'll will go back
on this ASAP.

-- 
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] BUG report: FindCygwin.cmake

[Eric Noulard]

2010/7/8 Aeschbacher, Fabrice :
> Hi,
>
> FindCygwin.cmake try to find Cygwin installation as follows:
>
>  FIND_PATH(CYGWIN_INSTALL_PATH
>    cygwin.bat
>    "C:/Cygwin"
>    "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Cygnus Solutions\\Cygwin\\mounts 
> v2\\/;native]"
>  )
>
>
> Unfortunately, recent versions of Cygwin do not install this registry key 
> anymore,
> but this one:
>
>
>   [HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup]
>   "rootdir"="D:\\cygwin"

The better way to report this kind of thing would be to open a bug on
the tracker
http://public.kitware.com/Bug/my_view_page.php
and may be add a patch proposal for 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] FILE command working

[Eric Noulard]

2010/7/9 Johny :
> On 07/09/2010 11:31 AM, Michael Wild wrote:
>>
>> On 9. Jul, 2010, at 11:24 , Johny wrote:
>>
>>
>>>
>>> Hi,
>>>
>>> I was working with the FILE(STRINGS filename lineList) and i discovered
>>> that i end up getting a list which has a lesser number of strings than the
>>> actual lines in the file. However this happens with only some files, i went
>>> through those but they seem to be regular files. When i count the no of new
>>> lines in the files i get the correct no of lines for the file.
>>>
>>> This has led me to believe that the FILE strings command is at fault
>>> somehow. How does it work?
>>>
>>> Cheers!
>>> Johny
>>>
>>
>> Just an idea, but do these files contain mixed line endings (i.e. some
>> lines end on \n, others on \r\n)?
>>
>> Michael
>
> nope i checked for that too. Its not the case

May be you can send us an example of such file ?
It would be easier to investigate.

-- 
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] CTest examples

[Eric Noulard]

2010/7/9 Bo Thorsen :
> Hi people,
>
> I have converted a set of applications to cmake and cpack, and now have my
> eyes set on ctest.
>
> I'd like to hear if someone here has some good advice, or links to good
> advice, on how to structure tests. I'm searching for help on how to put
> different tests into what executables. On how to handle multiple tests on
> each classes, on how to best structure the test of the static libraries (all
> of those are part of the source tree) that are linked in to the application.
> And on how to test classes from the main application itself.
>
> I have read the ctest FAQ, documentation etc. and still don't know anything
> that help me write the actual test code.
>
> From the looks of it, ctest only provides the framework to run a test, no
> help is given to write the code of the tests themselves, is this right? I
> have previously been using cppunit, and it looks like this will still be
> useful.

Yes you are right.
CTest is helping for running tests using "Test Driver".
CTest is useful for continuous integration if you use it with CDash
and for that part (from my point of view) it's useful if do not have
test at all, because you may monitor build breakage on various platform.

It helps even more if the tests application (which may be written using cppunit)
is built using CMake and/or is linked with the library your are
building (with CMake ...)

in an
add_test(NAME TestName
  COMMAND  TestProg)

TestProg (the Test Driver) may be built from an
add_executable(TestProg TestProg.c)
target_link_libraries(TestProg TheTestedLib)

or it may be a custom script (Python or anything you like)
or it may be a custom script which has been "configured" at CMake
time using configure_file

> To sum it up, I'm looking for real life advice on what you guys have done
> with ctest. This information seem almost completely missing on the net,
> where all searches on ctest leads to useless presentation on ctest features.

Real life usually depends on your life but...
Speaking for myself on two small projects (C and/or C++) I do use
simple (C or C++) test driver applications for basic unit test and
some python scripts for integration tests.

My [compiled C/C++] test drivers simply return 0 if the test is
successfull and something
else if not. CTest understand that out-of-the-box which makes it easy to see
unit test breakage using a simple "make test".

My Python script is driving several interacting applications (from 2 up to 10)
which are part of the build, in the same way the python script return non zero
value on error.

Since the whole testsuite may be running for a long time I'm using CTest
during development in order to easily select test to be run on a particular area
using

ctest -R  = Run tests matching regular expression.

I have my own naming rules for tests name which makes it easy to use.

I'm not using any unit test framework but I think there has already been some
discussion about mixed CMake/CTest CppUnit usage on this list.

Now I really cannot ensure that those advices will be as good
for you as they are too 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] CMakeCache Files

[Eric Noulard]

2010/7/14 Benjamin Eikel :
> Hello Mike,
>
> Am Mittwoch, 14. Juli 2010, 17:33:57 schrieb michael.schm...@l-3com.com:
>> I'm a newbie with cmake, and I wanted to clarify a couple things.  From
>> what I understand, there's no command to clear CMakeCache files.  If I
> the program cmake-gui has a menu option "Delete Cache".
>> add a new file or change the CMakeLists, then I have to delete the
>> CMakeCache files manually.  If I change an option using ccmake, do I
>> have to remove the cache files before "generating"?
> I do not think that this is necessary. CMake should overwrite the according
> values.

In "classical" use like updating your CMakeLists.txt and adding files
you don't need to  delete cache.

Sometimes you do but as you said you are a newbie you may not
need it until some weeks :-)

If you encounter weird CMake errors cleaning the whole build tree
is usually a good idea though.

-- 
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.2 win32: invalid escape sequence when finding fortran compiler

[Eric Noulard]

2010/7/14 John Drescher :
> On Wed, Jul 14, 2010 at 11:15 AM, Verweij, Arjen  
> wrote:
>> Hi,
>>
>>>
>>>You seem to have a path using \ instead of /
>>>
>>
>> Isn't that to be expected of a PATH setting on a Windows computer?
>> Anyway, the path to the Visual Studio compiler is of the same format and 
>> cmake deals with it just fine.
>>
>
> I use / for all paths inside my CMakeLists.txt files even on windows
> computers. If I am grabbing paths from the environment I use a string
> replace in the CMakeLists.txt
>
> string (REPLACE "\\" "/" PGM_FILES $ENV{PROGRAMFILES})

file(TO_CMAKE_PATH "$ENV{PROGRAMFILES}" PGM_FILES)

should work as well.

see the file command for details.


-- 
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] Finding Python3

[Eric Noulard]

2010/7/18 Alan W. Irwin :
[...]

> # Get the Python version.
>  execute_process(
>    COMMAND
>    ${PYTHON_EXECUTABLE} -c "import sys; print sys.version.split()[0]"
>    OUTPUT_VARIABLE PYTHON_version_output
>    OUTPUT_STRIP_TRAILING_WHITESPACE
>    )
>  SET(PYTHON_VERSION ${PYTHON_version_output} CACHE STRING "Python version")
>
> (We use this approach currently in PLplot.)  One caveat is the result of
> the above sometimes has trailing information that needs to be trimmed
> off.  For example, on my current system the result is "2.6.5+".

"import sys; print sys.version.split()[0]" will not work with python 3 because
print is a function:
http://docs.python.org/release/3.0.1/whatsnew/3.0.html

so you'd rather use:

"import sys; print(sys.version.split()[0])"

Now you can avoid the trailing informations if you use "sys.version_info"
instead of "sys.version".

On 2.6.5+ you get something like:

>>> print(sys.version_info)
(2, 6, 5, 'final', 0)

while on 3.1.x
>>> print (sys.version_info)
sys.version_info(major=3, minor=1, micro=2, releaselevel='final', serial=0)

using separate

sys.version_info[0]
sys.version_info[1]
sys.version_info[2]

should work both with python 2.[56].x and 3.x.y.

-- 
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] Library Paths

[Eric Noulard]

2010/7/19  :
> When I do an in-source build, everything runs ok.  However, I have
> issues with an out-of-source build.  One of my libraries uses another
> one of my libraries.  When I run the executable it complains "cannot
> open shared object file: No such file or directory."

linking your executable to those libs or are you doing
something like "dlopen" inside your application?

> It's looking for the library in the source directory and not the build tree.  
>I've read
> the wiki page on setting the rpath, but none of those combinations seem
> to work.

Are your speaking of this page:
http://www.cmake.org/Wiki/CMake_RPATH_handling ?

If yes it usually works for me with:

# use, i.e. don't skip the full RPATH for the build tree
SET(CMAKE_SKIP_BUILD_RPATH  FALSE)

# when building, don't use the install RPATH already
# (but later on when installing)
SET(CMAKE_BUILD_WITH_INSTALL_RPATH FALSE)

> I appreciate any help.

Which version of CMake ?
What is you platform ?

Supposing your are on Linux
Does it work if you setup LD_LIBRARY_PATH by hand?
Could you run
$ ldd yourapplication


-- 
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 skip checking compiler detection??

[Eric Noulard]

2010/7/21 sheissj :
> Hello.
>
> I want to generate a simple Makefile from cmake.
> This Makefile looks like this:
>
> all:
>     @echo "No build"
>
> tags:
>     ctags -R *.cpp
>     cscope -b -q -k *.cpp
>
>
> This simple Makefile do not have target to build source code. It is only for
> building ctags index and cscope db.
> So it is not a matter whether c/c++ compiler exists or not.
>
> How can I write CMakeList.txt for this simple work?
>
> One problem is... when "cmake ." command is run, some errors are occured
> like "The C compiler identification is unknown" and "The C++ compiler
> identification is unknown" and blar blar because I use cygwin and gcc/g++ is
> not installed.
> How to skip checking compiler detection?

at the top of your CMakeLists.txt you should have something like:

PROJECT(MakeTags NONE)

This will prevent CMake from enabling the default C and CXX languages.

then your "tags" target may be done with
add_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] Bug? project(X T) returns weird error

[Eric Noulard]

2010/7/21 Olaf van der Spek :
> Hi,
>
> I forgot to use quotes, but cmake doesn't make that obvious.
> Shouldn't it return a better error message?
>
> $ cat CMakeLists.txt
> project(X T)

If you read the documentation from the "project" command you read:

project( [languageName1 languageName2 ... ] )

Thus you  are asking for the "T" language.

> $ cmake .
> CMake Error: Error required internal CMake variable not set, cmake may
> be not be built correctly.
> Missing variable is:
> CMAKE_T_COMPILER_ENV_VAR

Which is not found :-)

I'm not sure what you mean by " I forgot to use quotes"

-- 
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: default to standard Debian package file names

[Eric Noulard]

2010/7/21 Olaf van der Spek :
> On Wed, Jul 21, 2010 at 5:39 PM, Droscy  wrote:
>> Hi Olaf,
>>
>> Olaf van der Spek ha scritto:
>>> Could this be changed to "xbt-tracker_0.1.1_i386.deb"?
>>>
>> I'm using the following code to obtain a correct debian-name
>
> Looks good, but this should really be part of the generator.

There is a bug report for that trouble:
http://public.kitware.com/Bug/view.php?id=9900

Currently there is no way to have a CPack Generator specific override
done by the specific generator.

However the user may choose the name by setting
CPACK_PACKAGE_FILE_NAME
in its CMakeLists.txt (as in the Droscy's example).

The limitation here is that you cannot generate 2 differents packages
(say RPM and DEB) with different naming convention
on the same host. (or you need at least two differents build trees).

-- 
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: Detecting if to build DEB/RPM packages

[Eric Noulard]

2010/7/22 Freddie Witherden :
> Hi,
>
> I use CPack in my project to build binary packages as an alternative to `make
> install`.  However, I am interested in getting my project to automatically
> detect which packages to build.
>
> Currently I have TGZ set and then require the user to pass the appropriate
> parameter to `cmake` (such as -DCPACK_BINARY_DEB:BOOL=on) to have deb/rpm
> packages made.
>
> I wish to know how I can have CMake/CPack determine if it is possible to build
> an RPM or DEB package on the system (so if all the required utilities are
> installed) and if so to go ahead and package them.

I did wrote a small CMake scripts which may help you for this.
add
include(SystemSpecificInformations)
to your CMakeLists.txt

then
SPECIFIC_SYSTEM_PREFERED_CPACK_GENERATOR
should contain the appropriate name of the CPack generator to be used
on the host.

Note however that the current script does not check whether if appropriate tool
(dpkg, rpmbuild, NSIS,...) are installed but basically associate an
host type with
a "prefered" CPACK_GENERATOR.

Windows --> NSIS
Debian --> DEB
Ubuntu --> DEB
Fedora --> RPM
SuSE --> RPM
other linux --> TGZ

> This would simplify things for people who checkout the project as they just
> need to type `make package` and can be sure of the appropriate package being
> built.
>
> However I am unsure how to reliably go about the detection process.  (Asking
> CMake to produce an RPM package on my Debian Squeeze system only fails when
> one tries to make the package -- after `cmake` has run.)

Yes and normally it fails by saying that you need to have "rpmbuild"
installed right?

something like:
CMake Error at /usr/share/cmake-2.8/Modules/CPackRPM.cmake:195 (MESSAGE):
  RPM package requires rpmbuild executable

Now I'm not sure we may do anything better, because you may effectively
want to build RPM on a debian host, even if this is not the 'native
package format'.
In fact on your Debian-based system if you "aptitude install rpm" you'll be able
to build RPM just fine.

I personnally usually build both DEB and RPM on my debian host.
This way I may easily build RPM for my collegue that do not want to
"compile themself".

That said you are right, in your case it would be interesting to build
the "prefered" package
automatically. May be you can file a feature request on the bug
tracker and we may submit
a enhance version of my "SystemSpecificInformations.cmake" which may
be integrated in CMake upstream.

What do other listeners think about that?

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


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

[CMake] Fwd: CPack: Detecting if to build DEB/RPM packages

[Eric Noulard]

Forgot the list


-- Forwarded message --
From: Eric Noulard 
Date: 2010/7/22
Subject: Re: [CMake] CPack: Detecting if to build DEB/RPM packages
To: norulez 


2010/7/22 norulez :
> This shouldn't work, because you could build deb packages on redhat systems 
> with cpack without any deb tools installed

Yes true.
You must know you have limitation like not automatically choosing the
appropriate "architecture" for the package.

DEB generator uses
dpkg --print-architecture
in order to select approprite arch.

if dpkg is not found then the default is i386, which may not be what you want
e.g. on an x86_64 system.

The scheme is better than nothing though.

--
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] Bug? project(X T) returns weird error

[Eric Noulard]

2010/7/21 Brian Davis :
> I agree with Olaf.  CMake needs better error reporting for parameter
> checking on macros and functions

Good idea but this seems difficult to do.
In Olaf case it may be doable to spit out a better error message explicitely
saying that "T" was considered as the "" argument of PROJECT,
because PROJECT is a builtin

however...

> I ran into similar with use of:
>
> http://www.cmake.org/Wiki/CMakeMacroParseArguments
>
> where I elided the empty quotes "" and it was as though the macro/function
> it was contained in did not exist as though it could not find the ending
> paren ")".  I realize I should always use functions as specified, but as
> humans inevitably make mistakes it's best to have decent error reporting so
> we can correct our ways.
[...]

In this case the MACRO CMake command has only "positional" arguments handling.
So if you miss-use the ParseArguments macros the better you can do is enhance
the ParseArguments macro in order to do a better job while checking
its arguments.

May be the only way to have a better error reporting would be to have a new

kwmacro( KEYWORD  arg1 KEYWORD kw2 arg2  KEYWORD  kwN argN)

kwmacro()

that would support keyword call instead of positional call.
i.e.

kwmacro(PARSE_ARGUMENTS
  KEYWORD PREFIX prefixarg
  KEYWORD ARGNAMES argnames
  KEYWORD OPTIONSNAME optnames)

kwmacro(PARSE_ARGUMENTS)

then you MUST call
PARSE_ARGUMENTS(hello world
  PREFIX ARG
  ARGNAMES "LIST1;LIST2;LIST3"
  OPTIONSNAME "OPTION1;OPTION2;OPTION3")

i.e. non keyword argument MUST be given before ANY keywords arg
(pretty much like in Python).

kwmacro as a builtin would set for you

KW__GIVEN to TRUE is the  have been given.
KW__ARGS to the list of arguments given to .
KW_DEFAULTS_ARGS will be the list of positional arguments.

basically it is the feature provided by PARSE_ARGUMENTS but as a
more robust builtin.

-- 
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: default to standard Debian package file names

[Eric Noulard]

2010/7/22 Olaf van der Spek :
> On Wed, Jul 21, 2010 at 7:40 PM, Eric Noulard  wrote:
>> http://public.kitware.com/Bug/view.php?id=9900
>
> What's stopping this bug from being fixed?

>From my point of view: lack of time :-)
However for my next CMake developping session
[which is not planned]  this one is on my top-2 list.

More generally, I think it is NOT a show-stopper for most of CMake user,
at least it didn't show up on the "next" wishlist call:
http://www.cmake.org/pipermail/cmake/2010-July/037911.html

It should be handled with care in order to avoid backward compatibilty breakage.
CMake developers may have more/differents answer to that question too.

Besides that I think patch (or paid work) would be welcomed as usual :-)
I'll be happy to try a patch, if you try please attach it to the bug tracker
and/or give a public git repo url one can merge from.

-- 
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: default to standard Debian package file names

[Eric Noulard]

2010/7/22 Olaf van der Spek :
> On Thu, Jul 22, 2010 at 10:56 AM, Eric Noulard  wrote:
>> 2010/7/22 Olaf van der Spek :
>>> On Wed, Jul 21, 2010 at 7:40 PM, Eric Noulard  
>>> wrote:
>>>> http://public.kitware.com/Bug/view.php?id=9900
>>>
>>> What's stopping this bug from being fixed?
>>
>> From my point of view: lack of time :-)
>> However for my next CMake developping session
>> [which is not planned]  this one is on my top-2 list.
>>
>> More generally, I think it is NOT a show-stopper for most of CMake user,
>> at least it didn't show up on the "next" wishlist call:
>> http://www.cmake.org/pipermail/cmake/2010-July/037911.html
>
> True.
>
> A more important issue is the lack of automatic dependency generation
> for Debian based on the executable. Is there an issue in the tracker
> for this too?

Yes there is:
http://public.kitware.com/Bug/view.php?id=10292

Note that you can search the bug tracker using filter for CPack or DEB 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] CPack DEB: default to standard Debian package file names

[Eric Noulard]

2010/7/22 Olaf van der Spek :
> On Thu, Jul 22, 2010 at 11:33 AM, Eric Noulard  wrote:
>> Note that you can search the bug tracker using filter for CPack or DEB etc...
>
> I can set Category = CPack, but where can I set DEB?

There is no "DEB"  (nor TGZ, NSIS etc...) Category but you do a keyword search
on every field using teh "search box" of the filter
(bottom left part if you did unfold filter)

-- 
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: Detecting if to build DEB/RPM packages

[Eric Noulard]

2010/7/22 Olaf van der Spek :
> On Thu, Jul 22, 2010 at 4:08 PM, Freddie Witherden
>  wrote:
>> I'll try adding a check for `rpmbuild` to my CMakeLists before enabling RPM 
>> packages.  This seems quite a nice solution as users should always get TGZ 
>> and DEB and RPM if possible.  From what I gather producing DEBs has no 
>> associated dependencies.
>
> Won't the deb generator soon have a dependency on the tool to generate
> the dependencies list?

Yes it should, if ever the proposed patch
http://public.kitware.com/Bug/view.php?id=10292
is merged as-is.

My opinion concerning DEB and RPM is that it seems better
to rely on specific tools (dpkg-xxx and rpm/rpmbuild) if we want to
get "proper" package.

Trying not to depends on those tools lower the possibility
of the produce package (like lacking auto-dependencies)
and/or produce bad behaving package.

We may even think that building an rpm on a debian based host
is a non-sense even if rpm tools can be installed on debian.

Note that if ever ones lacks some package format support
alien may be the tool of choice: http://kitenet.net/~joey/code/alien
even if alien itself relies on supporting tools...

but now I'm really goiing off-topic ...stopping 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] CPack: Detecting if to build DEB/RPM packages

[Eric Noulard]

2010/7/22 Olaf van der Spek :
> On Thu, Jul 22, 2010 at 11:08 PM, Eric Noulard  wrote:
>> Yes it should, if ever the proposed patch
>> http://public.kitware.com/Bug/view.php?id=10292
>> is merged as-is.
>
> What's the delay?

I do not have an authoritative answer,
I'm not Kitware employee just a bare CMake contributor.

I let Kitware employee answer that one.

-- 
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: Detecting if to build DEB/RPM packages

[Eric Noulard]

2010/7/25 Alexander Neundorf :
> On Thursday 22 July 2010, Eric Noulard wrote:
>> 2010/7/22 Olaf van der Spek :
>> > On Thu, Jul 22, 2010 at 11:08 PM, Eric Noulard 
> wrote:
>> >> Yes it should, if ever the proposed patch
>> >> http://public.kitware.com/Bug/view.php?id=10292
>> >> is merged as-is.
>> >
>> > What's the delay?
>>
>> I do not have an authoritative answer,
>> I'm not Kitware employee just a bare CMake contributor.
>
> Don't you have commit access ?

Yes I do.

But I was granted commit access for CPackRPM and I don't want
to abuse my commit "trust" on every patch I found OK :-)

Switching cmake-devel in order to go on with this discussion
on CPackDeb related patches?


-- 
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: Detecting if to build DEB/RPM packages

[Eric Noulard]

2010/7/25 Olaf van der Spek :
> On Sun, Jul 25, 2010 at 7:13 PM, Eric Noulard  wrote:
>> Switching cmake-devel in order to go on with this discussion
>> on CPackDeb related patches?
>
> I don't see cmake-devel at http://www.cmake.org/cmake/help/mailing.html
> How come?

Don't know.

It is not listed there but it is accessible here:
http://www.cmake.org/mailman/listinfo/cmake-developers

The list is usually used by CMake developers/contributos to
discuss issue which would usually annoy "normal" CMake users :-)

- Like how use git for doing that?
- How come my commit is refused by git with this cryptic message "blah blah..."


-- 
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] Problem with current CVS HEAD for creating ZIP with shared lib on Linux

[Eric Noulard]

2010/1/19 Eric Noulard :
> 2010/1/19 Bill Hoffman :
>>>
>> You should file a bug.  This most likely is because we switched to
>> libarchive for creation of the tar and zip files.
>
> Done:
> http://public.kitware.com/Bug/view.php?id=10162

Small update,

I have just updated the bug (and unassigned it) since it looks
like this is currently a libarchive limitation concerning the zip format.

libarchive zip handling cannot handle symbolic links,
tar is OK.


-- 
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] Debug/Release configurations for codeblocks ?

[Eric Noulard]

2010/7/26 Olaf van der Spek :
> On Mon, Jul 26, 2010 at 7:23 PM, Michael Wild  wrote:
>> OK, it's like this: CMake has various "backends" which generate the native 
>> build tool. For MSVC, GNU Make, nmake, Xcode etc. Now, some of these 
>> backends are "multi-config", such as the ones for MSVC and Xcode. That 
>> means, the same project file can generate multiple configurations (e.g. 
>> Debug, Release or RelWithDebugInfo). Others, the Makefile based ones (GNU 
>> Make and nmake) are "single-config", where the build system generated by 
>> CMake can only build a single configuration which the user selected when 
>> configuring the build tree.
>>
>> Since the CodeBlocks generator is actually the "GNU Makefiles" generator 
>> with the addition of the CodeBlocks project file, it inherits these 
>> characteristics and can only build a single configuration.
>>
>> Hope this clears things a bit.
>
> Thanks a lot.
> So the Code Blocks gen isn't native? Just uses a makefile for the
> build system. That explains it.

It depends on what you mean by "native".
The project file for Code::Blocks is generated by CMake but
Code::Blocks may be used with "external" makefile(s)
which are generated by CMake too.

You have the same scheme with the Eclipse CDT4 generator.
Those generatord are "Extra" generator which relies on the Makefile generator.

You may have a look at the source for:

CMake/Source/cm[Local|Global|Extra]Generator.[h|cxx]

XXX being [part of] the generator name the user is used to know.

"Extra" means the generator depends on another generator
I don't know the design idea behind Local and Global.


-- 
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] Debug/Release configurations for codeblocks ?

[Eric Noulard]

2010/7/26 Olaf van der Spek :
> On Mon, Jul 26, 2010 at 8:32 PM, Eric Noulard  wrote:
>>> Thanks a lot.
>>> So the Code Blocks gen isn't native? Just uses a makefile for the
>>> build system. That explains it.
>>
>> It depends on what you mean by "native".
>> The project file for Code::Blocks is generated by CMake but
>> Code::Blocks may be used with "external" makefile(s)
>> which are generated by CMake too.
>
> By native I mean what Code Blocks projects use by default. I assume
> they don't use an external makefile.

No you are right the default is to use some "builtin" project file and
dependency tracking etc...

Now if you look at the Eclipse CDT4 generator this difference blurs
because Eclipse CDT do use Makefiles bu they can be "managed"
(generated by Eclipse CDT) or "custom/unmanaged" and that's
the way it is used with CMake Eclipse CDT generator.


-- 
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] [VS gen] Multiple configurations code

[Eric Noulard]

2010/7/26 Olaf van der Spek :
> On Mon, Jul 26, 2010 at 10:12 PM, David Cole  wrote:
>>> Is there a problem with multiple configures / build trees?
>>
>> No, not at all. We do this all the time. But again, I thought from your
>> questions that you were trying to do it all in one build tree.
>
> I'm not familiar with the term build tree.

You may have a look at this part of the FAQ:
http://www.cmake.org/Wiki/CMake_FAQ#Out-of-source_build_trees

Basically from CMake point of view, all **generated** files are in the
build tree.
Note that **generated** files does mean that those files are coming
from a compilation step
they may come from add_custom_command, execute_process etc...

One thing that interest you in the first place is that the project
file (or makefile etc...)
is GENERATED so it ends up in the build tree.

So having 2 separate build trees == having 2 separate project files.

The main idea behind the source-tree / build-tree separation is that
you may always delete the build tree because it may be regenerated from
the source tree.
This way if you use a VCS (CVS, svn git, etc...) you know that the VCS
is only concerned
by the source tree.
A last thing is that a source tree may be "shared" by several build trees.


> Let's describe what I'd like:
> I've got a single CMakeLists.txt for a lib named "xbt". I've got xbt.h
> and xbt.cpp. I'm using VS (2010).
> With a few simple commands, I should be able to build and package all
> possible configurations of this lib.
> In the ideal case, this would be cmake ., nmake ... or similar.
>
> It should not be necessary to modify CMakeLists or to have multiple
> copies of the source.

Currently you don't need several copies of the sources, you "only" need several
build trees configured with **differents** options from the SAME CMakeLists.txt.

Is it more clear, stated like 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

[CMake] bash completion for cmake

[Eric Noulard]

Here comes a proposal for a bash completion for cmake. Should work with almost
any cmake version because it's using cmake command to retrieve completion.

Prerequisite: You should have "bash-completion" package installed.

If you want to try  you may either:

1) add the attache "cmake" file to /etc/bach_completion.d/
2) source the file in your current (bash shell)
$ . .cmake

then

$ cmake  offers first level completion

$ cmake --help-command  offers second level completion

I don't know how to handle third level for now.

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


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] bash completion for cmake

[Eric Noulard]

2010/7/27 Eric Noulard :
> Here comes a proposal for a bash completion for cmake. Should work with almost
> any cmake version because it's using cmake command to retrieve completion.
>
> Prerequisite: You should have "bash-completion" package installed.
>
> If you want to try  you may either:
>
> 1) add the attache "cmake" file to /etc/bach_completion.d/
> 2) source the file in your current (bash shell)
>    $ . .cmake
>
> then
>
> $ cmake  offers first level completion
>
> $ cmake --help-command  offers second level completion

Here comes an updated file with some support for cpack and ctest too.

I did submit this as a proposal to bash-completion project:
https://alioth.debian.org/tracker/index.php?func=detail&aid=312632&group_id=100114&atid=413095

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


cmake-completion
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] bash completion for cmake

[Eric Noulard]

2010/7/28 Kishore :
> On Tuesday 27 Jul 2010 6:05:59 pm Eric Noulard wrote:
>> 2010/7/27 Eric Noulard :
>> > Here comes a proposal for a bash completion for cmake. Should work with
>> > almost any cmake version because it's using cmake command to retrieve
>> > completion.
>> >
>> > Prerequisite: You should have "bash-completion" package installed.
>> >
>> > If you want to try  you may either:
>> >
>> > 1) add the attache "cmake" file to /etc/bach_completion.d/
>> > 2) source the file in your current (bash shell)
>> >    $ . .cmake
>> >
>> > then
>> >
>> > $ cmake  offers first level completion
>> >
>> > $ cmake --help-command  offers second level completion
>>
>> Here comes an updated file with some support for cpack and ctest too.
>>
>> I did submit this as a proposal to bash-completion project:
>> https://alioth.debian.org/tracker/index.php?func=detail&aid=312632&group_id
>> =100114&atid=413095
>
> Thanks a lot for this. Unfortunately it does not work here. This is what i get
> with "cmake "
>
> $ cmake _get_comp_words_by_ref: command not found
> -_get_comp_words_by_ref: command not found

Are you sure "bash-completion" package is installed ?

You can verify with:

$ dpkg-query -W bash-completion

which should answer something like:

bash-completion 1:1.2-2

or some sort of error saying the package is not found.

If not found, you may install the package with:

sudo aptitude install bash-completion

then retry cmake completion.


-- 
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] bash completion for cmake

[Eric Noulard]

2010/7/28 Kishore :
>>
>> bash-completion       1:1.2-2
>
> bash-completion 1:1.1-3ubuntu2

I think I know why. The missing functions may comes with bash-completion 1.2
you have 1.1.

Would you try the attach file it should work with 1.1 (and 1.2)


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


cmake-completion-forBC1-1
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] CPackDeb generator patch

[Eric Noulard]

2010/2/13 Thawan Kooburat :
> Hi,
>
> I created a patch for CPack Debian generator. Here is the list of my
> modification
>
> -  Automatically generate dependency list if dpkg-shlibdeps utility is
> presented.
>       1. Detect if dpkg-shlibdeps is existed in the system
>       2. Use "find" and "file" command to generate a list of file and its type
>       3. Only dynamically linked ELF binary are sent to
> dpkg-shlibdeps  to generate the dependency list
>       4. Final dependency list  =  dpkg-shlibdeps  + user-specified depends
>
> - Change how top-level directories are detected - existing method
> ignores blank directories
>
> - Automatically set permission of control scripts to 07555  (prerm,
> preinst, postrm, postinst)
>
> - Add one more Debian control file field -
> CPACK_DEBIAN_PACKAGE_HOMEPAGE (optional field)
>
>
> Any comments is welcomed and I hope that all of these features get
> included into the future release of CPack

Part of your proposal have been checked-in.
Would have a look at the bug report comment please:
http://public.kitware.com/Bug/view.php?id=10292

-- 
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] Does the echo command use the system shell?

[Eric Noulard]

2010/7/28 Óscar Fuentes :
> For creating a file at build time with a content like this:
>
> #define foo "bar"
>
> I use this on Linux:
>
> add_custom_command(OUTPUT buildobj.h
>  COMMAND ${CMAKE_COMMAND} -E echo "\\#define foo \\\"bar\\\""
>  > buildobj.h
>  )
>
> but that doesn't work on Windows, because it outpus:
>
> \#define foo "bar"
>
> Removing the backslashes before `#' fixes the problem on Windows, but
> then breaks the Linux build.
>
> This looks as if `echo' was using the system shell for doing the job,
> because the escapes works differently on each system.
>
> What's the right way to write the above command so it works on all
> platforms?

If you want to write to a file, you'd rather use

file(WRITE ...)
file(APPEND ...)

or

configure_file(...)

since those commands are CMake time commands, if you need build
time creation of the file then you may write a CMake script
"generateMyFile.cmake" which contains such commands and use

add_custom_command( ...
  COMMAND ${CMAKE_COMMAND} -P generateMyFile.cmake
   ...)


If you are trying to write some kind of "config.h" things you may
find this link useful:
http://www.cmake.org/Wiki/CMake:How_To_Write_Platform_Checks

-- 
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] Does the echo command use the system shell?

[Eric Noulard]

2010/7/28 Óscar Fuentes :
> Eric Noulard 
> writes:
>
> [snip]
>
>> if you need build
>> time creation of the file then you may write a CMake script
>> "generateMyFile.cmake" which contains such commands and use
>>
>> add_custom_command( ...
>>   COMMAND ${CMAKE_COMMAND} -P generateMyFile.cmake
>>        ...)
>
> That approach justs shifts the problem to a separate cmake script, but
> it still remains.

I think you are wrong.

May be you can try the attach script.

try:
cmake -DYOURSTRING="I like # \ it" -DTHE_FILE=toto.txt -P writeany.cmake

You shouldn't have "quite" problem with the previous approach.

> The task here is to write a literal string containing a "special"
> character (#) to a file, at build time. For "cmake -E echo" it requires
> platform-dependent escape sequences. My idea about the cmake -E commands
> was that they purpose is to abstract platform differences, but seems
> that that is not entirely correct, as they inherit some traits from the
> underlying platform. Or is it a bug?

I would say a feature :-)

You do not want to have to "escape" some sequences but you expect
redirection to work...
So ">" should have the appropriate meaning ?
What about "2>" ?

More seriously
I think it's complicated to avoid system specific issues with a
command like "echo".
I think that if you tell me what you would expect I may probably gives
you an example
of mine were YOUR bug is a feature for ME.

That said, that's my own opinion, I may be wrong.
-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org

file(WRITE ${THE_FILE} "#include whatever\n")
file(APPEND ${THE_FILE} "${YOURSTRING}\n")
___
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] library name from subdirectory and setting the CACHE - a "listening" variable?

[Eric Noulard]

2010/7/28 Clifford Yapp :
> Ironically, I now see this issue (almost exactly) was discussed long ago:
>
> http://www.cmake.org/pipermail/cmake/2005-September/007204.html
>
> However, when I try:
>
> get_directory_property(PNG_LIB_NAME DIRECTORY src/other/libpng
> DEFINITION PNG_LIB_NAME)
> MESSAGE("getdirprop: ${PNG_LIB_NAME}")
>
> I get nothing - anybody have a worked example using this feature?

I must admit I did not read your previous mail entirely but
did you notice that:

get_directory_property
   Get a property of DIRECTORY scope.
 [...]
  The specified directory must have already been
   traversed by CMake.

That is if the parent is retrieving daugther directory property BEFORE
the daughter was traversed then you won't get anything.

As far as I understand "add_subdirectory" doc, the subdirectory are traversed
"in-depth" first since
"The CMakeLists.txt file in the specified source
   directory will be processed immediately by CMake before processing in
   the current input file continues beyond this command."

so if want to get_directory_property from a daughter dir then you
ensure that add_subdirectory to the target dir appear before
get_directory_property.

Is it the case in your example?

Do you have a small example which exhibit the "get_directory_property" 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] Does the echo command use the system shell?

[Eric Noulard]

2010/7/29 Óscar Fuentes :
> Eric Noulard 
> writes:
>
>> I think you are wrong.
>>
>> May be you can try the attach script.
>>
>> try:
>> cmake -DYOURSTRING="I like # \ it" -DTHE_FILE=toto.txt -P writeany.cmake
>>
>> You shouldn't have "quite" problem with the previous approach.
>
> I tried this on Linux:
>
> add_custom_command(OUTPUT ${EMACS_BUILD_DIR}/src/buildobj.h
>  COMMAND cmake -DYOURSTRING="#define BUILDOBJ" -DTHE_FILE=buildobj.h -P 
> writeany.cmake
>  COMMENT "Creating buildobj.h"
>  )
>
> It didn't create the file.

If this not created the file then there must be an error during the execution
of the custom command.

When this happen you should try: make VERBOSE=1

> So tried this:
>
> add_custom_command(OUTPUT ${EMACS_BUILD_DIR}/src/buildobj.h
>  COMMAND cmake -DYOURSTRING="\#define BUILDOBJ" -DTHE_FILE=buildobj.h -P 
> writeany.cmake
>  COMMENT "Creating buildobj.h"
>  )
>
> It put this text on the resulting file:
>
> #define\ BUILDOBJ
>
> That's not quite what I wanted.

You are right and after thinking about it, I remember some discussion
occurs here on the usage of VERBATIM with custom command.

This should theoretically send the command line "as-is" as you expected but
I end up having  an unexpected behavior with:

add_custom_command(OUTPUT buildobj.h
  COMMAND ${CMAKE_COMMAND} -DYOURSTRING="#define BUILDOBJ"
-DTHE_FILE=${CMAKE_BINARY_DIR}/buildobj.h -P
${PROJECT_SOURCE_DIR}/writeany.cmake
  COMMENT "Creating buildobj.h"
  VERBATIM
  )

because the generated command line (seen with make VERBOSE=1) is

cmake -DYOURSTRING= "#define BUILDOBJ"
-DTHE_FILE=/full/path/to/buildobj.h -P /full/pathto/writeany.cmake

which DOESN'T work because of "stupid" whitespace inserted between

-DYOURSTRING=
and
"#define BUILDOBJ"

Looks like a bug.

Now you know VERBATIM you would be tempted to write:
add_custom_command( OUTPUT buildobj.h
   COMMAND cmake -E echo "#define FOO 1" > build.h
   VERBATIM)


but this doesn't work either because the ">" is not interpreted as a redirection
anymore :-(

>>
>> I would say a feature :-)
>>
>> You do not want to have to "escape" some sequences
>
> I'm happy escaping whatever as much sequences as necessary. What is not
> okay is to change escape rules depending on the plataform (or worse,
> depending on the shell cmake uses for the generator. "Mingw Makefiles"
> -> cmd.exe, "MSYS Makefiles" -> sh.exe)

Agreed, but last message from Andreas
seems to show there exist an appropriate cross-platform solution.
Thanks to him for that.

I must admit the solution is "not so" obvious though.

>> More seriously I think it's complicated to avoid system specific
>> issues with a command like "echo".
>
> It should be possible to pass an arbitrary string (containing
> backslashes if necessary) to "echo" and send it to the console or
> redirected to a file on a platform independent way. That means avoiding
> any middleman that may reinterpret certain characters as per its own
> rules.

it should be the goal of VERBATIM option but you lose redirection too.
Excerpt from VERBATIM option doc (sub paragraph of add_custom_command):

"Use of VERBATIM is recommended as it enables
   correct behavior.  When VERBATIM is not given the behavior is platform
   specific because there is no protection of tool-specific special
   characters."

>> I think that if you tell me what you would expect I may probably gives
>> you an example of mine were YOUR bug is a feature for ME.
>
> I doubt that, because on the end we want the same: saying "take this
> string and put it on that file." We can then open the file and test
> that, effectively, the string is there.

May be I was too pushy on that, sorry.

-- 
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] library name from subdirectory and setting the CACHE - a "listening" variable?

[Eric Noulard]

2010/7/29 Clifford Yapp :
> Got it - was using a VTK macro for third_party inclusion that was
> using SUBDIRS - switching it to ADD_DIRECTORY got me going.  Awesome!

SUBDIRS is deprecated but it's good to know that it's behavior
is not strictly equivalent to  ADD_DIRECTORY in some 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] Linker problems with compiling static QT lib with cmake

[Eric Noulard]

2010/7/29 bal...@t-online.de :
>
> Hello,
>
> I am trying to compile a simple QT HelloWorld.cxx with cmake. I have a 
> statically compiled qt installed as well as a non static version.
> What I want is a statically compiled HelloWorld. Cmake allows me to choose my 
> static build of QT (using cmake-gui) by choosing the qmake
> binary in the static qt lib folder. When I do this it automatically changes 
> the other entries like QT_LIBRARY_DIR to the static version. Looks great
> so far.
> Here the problems begin though:
> If I just generate my Makefile and make without adding CMAKE_EXE_LINKER_FLAGS 
> "-static", everything seems to work and my HelloWorld binary ist beeing 
> created. ldd reveals though that it has been linked against the shared 
> version of the lib:
>
>> ldd ./HelloWorld
>> libQtGui.so.4 => /usr/lib/libQtGui.so.4 (0x0011)
>> ...
>> ...
>
> This struck me as strange, as all entries in my generated CMakeCache.txt 
> point to my static install of QT which certanly is nowhere near /usr/lib (in 
> /usr/lib my nonstatic qt is installed). The result is, I have compiled a 
> working HelloWorld binary which is linked against my nonstatic version of QT 
> which cmake shouldn t even know about after changing the qmake binary path in 
> the cmake configure process.
>
> This is not the real problem though, since I want to compile it with 
> CMAKE_EXE_LINKER_FLAGS "-static". If I generate my Makefile with -static 
> option, make throws the following linker error:
>
> canning dependencies of target HelloWorld
> [100%] Building CXX object CMakeFiles/HelloWorld.dir/HelloWorld.cxx.o
> Linking CXX executable HelloWorld
> /usr/bin/ld: cannot find -lQtGui
> collect2: ld returned 1 exit status
> make[2]: *** [HelloWorld] Error 1
> make[1]: *** [CMakeFiles/HelloWorld.dir/all] Error 2
> make: *** [all] Error 2
>
> Somehow the linker cannot find the QtGui module, which is in my statically 
> compiled folder of QT under lib/libQtGui.a.
> Any ideas/solutions? I really have no idea at this point since everything 
> looks fine in the cmake config/generation process.
> My CMakeLists.txt looks like this:
>
>
> PROJECT(HelloWorld)
>
> cmake_minimum_required(VERSION 2.6)
>
> FIND_PACKAGE(Qt4)
>
> IF(QT4_FOUND)
>        INCLUDE(${QT_USE_FILE})
> ELSE(QT4_FOUND)
> MESSAGE(FATAL_ERROR
> "Qt4 not found. Please set QT4_DIR.")
> ENDIF(QT4_FOUND)
>
> ADD_EXECUTABLE(HelloWorld HelloWorld.cxx )
> TARGET_LINK_LIBRARIES(HelloWorld QtGui)

Shouldn't you use:

TARGET_LINK_LIBRARIES(HelloWorld ${QT_QTGUI_LIBRARY})

note that from the FindQt4 module one can read:

"  Typical usage could be something like:

  find_package(Qt4 4.4.3 COMPONENTS QtCore QtGui QtXml REQUIRED )
  include(${QT_USE_FILE})
  add_executable(myexe main.cpp)
  target_link_libraries(myexe ${QT_LIBRARIES})"


more information with

cmake --help-module FindQt4


-- 
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] Linker problems with compiling static QT lib with cmake

[Eric Noulard]

Please do not forget to CC the list.

2010/7/29 bal...@t-online.de :
>> Shouldn't you use:
>>
>>TARGET_LINK_LIBRARIES(HelloWorld ${QT_QTGUI_LIBRARY})
>
> Well, if I am _not_ linking statically it works with 
> target_link_libraries(HelloWorld QtGui QtCore) without a problem.
> CMake then seems to link the shared libs though, which as I posted strucks me 
> as strange, since it shouldn t even know where
> my nonstatic qt ist installed. I only told CMake where my static qt lib is 
> located in the configure process.
>
>> note that from the FindQt4 module one can read:
>>
>> "      Typical usage could be something like:
>>
>> find_package(Qt4 4.4.3 COMPONENTS QtCore QtGui QtXml REQUIRED )
>> include(${QT_USE_FILE})
>> add_executable(myexe main.cpp)
>> target_link_libraries(myexe ${QT_LIBRARIES})"
>
> Well, that is indeed a first step, now the linker does find all the libs 
> which is good. I get tons of undifend reference errors now:

I did never develop a Qt app myself but I'm sure there is a lot
of people that do with CMake.

You may be missing something I don't know about CMake +Qt,
did you read the full documentation for FindQt4 ?
There are other specifically defined macros:
QT4_WRAP_CPP
QT4_WRAP_UI
QT4_ADD_RESOURCES
QT4_GENERATE_MOC
...

However in this area I cannot help,
and I let people with knowledge about Qt+CMake to help you.


> /home/user/Static_Libs/Qt/lib/libQtGui.a(qapplication_x11.o): In function 
> `sm_setProperty(char const*, char const*, int, SmPropValue*)':
> qapplication_x11.cpp:(.text+0x655): undefined reference to 
> `SmcDeleteProperties'
> qapplication_x11.cpp:(.text+0x68e): undefined reference to `SmcSetProperties'
[...]


> Btw.: I CAN link statically to my qt libs with qmake and it works great, so 
> my QT is definitly setup correctly. I need CMake though because I use an ITK 
> project.

I don't know qmake either :-(


-- 
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] controlling linker

[Eric Noulard]

2010/7/29 j s :
> I'm linking C++ static libraries against a c main.  On linux, cmake 2.6
> tries to use gcc for the final link. cmake 2.8.1 uses g++ for the final
> link.  How do I tell cmake 2.6 to use a c++ linker?

May be setting the LINKER_LANGUAGE
property on the target?

see
http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:LINKER_LANGUAGE


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

[Eric Noulard]

2010/7/5 David Cole :
> Hi all,
> Now that we have released CMake 2.8.2 last Monday, and we have switched to
> this new workflow using branches in the git repository, *now* would be a
> great time to prioritize bug fixes for the next release of CMake.
> We are leaning towards quarterly releases from now on, scheduling them every
> 3 months. That would make the next release of CMake version 2.8.3 and
> scheduled to have an "rc1" release candidate in approximately mid-September,
> 2010.
> If you have a particular issue that you think should be fixed for inclusion
> in 2.8.3, please bring it up now. Ideally, each issue will be discussed as
> needed on the mailing list to come to any consensus about what should be
> done to fix it, and then an entry in the bug tracker may be used to keep it
> on the radar screen, and to track activity related to it.
> Patches are always welcome. Patches that include testing of any new
> features, or tests that prove a bug is really fixed on the dashboards,
> basically any patch with testing is preferred over a patch with no testing.
> Also, if you are *adding* code, then you also probably need to add *tests*
> of that code, so that the coverage percentage stays as is or rises.
> Please discuss issues here as needed, and add notes to existing issues in
> the bug tracker that you are interested in seeing fixed for 2.8.3 -- we will
> be looking at the mailing list and activity in the bug tracker to help
> prioritize the bug fixes that will occur in the next several weeks.
>
> Thanks,
> David Cole
> Kitware, Inc.

So here goes my own list.

I'd like to fix 2 annoying relatively long-standing bugs:

1) "Make CPack generic generator delegate the name of the file to
specific generator"
 http://public.kitware.com/Bug/view.php?id=9900

(may be fixed together with
 http://public.kitware.com/Bug/view.php?id=10736)

2)  CPack RPM generator should always "CPACK_SET_DESTDIR"
http://public.kitware.com/Bug/view.php?id=7000

1) Should come first because it will help fix others "depending" bugs
related to this
one and makes it possible to use "standard" package name for at least
RPM and DEB.
May be it can be fixed together with
http://public.kitware.com/Bug/view.php?id=10736.
The idea would be for the CPack generic generator to offer a "new
compresFiles API"
in which the name of the package is both an input AND an output. Moreover
the output should be a vector of filenames and not a single filename.

2) In the same way this one is blocking some pending features for CPackRPM
(or CPackDEB) and the issue is raising from time to time on the list.

May be interested people could add themselves to the monitor list of
those bugs.


-- 
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] Support for multiple components in cpack

[Eric Noulard]

Hi All,
I'll try to launch a specific thread for this following what

Kishore said:
> I would like to see full support for multiple components in cpack.

David answered:
> Could you elaborate on "full support for multiple components in cpack" either 
> in another thread,
> or in a feature request bug in the bug tracker?
>
> With NSIS on Windows and PackageMaker on Mac, we already have what I would 
> consider "full support". Are you talking about
> extending that to additional CPack generators or is there something missing 
> even in those generators in your opinion?

An explanation on CPack Component may be found here:
   http://www.itk.org/Wiki/CMake:Component_Install_With_CPack

As David said currently the only 2 CPack generators which support Components are
   - NSIS
   - PackageMaker

I personally would like a wider support including RPM, DEB, TGZ (and
may be ZIP and other archive-like).
There is at least one bug/feature report/request for that for  CPackRPM:
http://public.kitware.com/Bug/view.php?id=7645

>From my point of view for the RPM/DEB/archive (TBZ2  TGZ   TZZIP)
COMPONENT installer there is two "global" options:

A) Put all the components in a single archive with some hierarchical
structure inside
i.e. build a TGZ   whose structure may be;
  toplevel-name/component1/...
  /component2/...
  etc...

B) Build as many files as components.
 toplevel-name-component1.tgz
 toplevel-name-component2.tgz
 toplevel-name-component3.tgz

The scheme A) is not quite usable for RPM or DEB
but it is ok for "pure" archive like TBZ2 , TGZ, TZ,  ZIP.

My **personal** opinion is that for this kind of installers I'd rather
go for B).
The current problem with B) is that current  CPack architecture does
not authorize it see:
http://public.kitware.com/Bug/view.php?id=10736

Like I said in another mail if we tackle the "multiple file problem" we should
be able to solve the "naming convention problem" too, see:
http://public.kitware.com/Bug/view.php?id=9900

So I would like those 2 bugs (9900, 10736)
solved, which would enable the may-be-easy creation
of full support for CPack COMPONENTs in any case (including bug 7645).

Please comment on those ideas or indicate whether if you agree with my
analysis or not.
Once we have some opinions ideas on this, I'll propose a new/updated
API for CPack generators
concerning 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] CPack integration

[Eric Noulard]

2010/8/1 Dennis Schridde :
> Hello!
>
> I just started experimenting with CPack. According to the docs and
> code it is to be used like this:
>> set(CPACK_... ...)
>>
> include(CPack)
>
> This, however, does not allow making use of the defaults
> present in CPack.cmake. (Most notably CPACK_SOURCE_IGNORE_FILES.)
> I had to
> copy the default value of that variable out of CPack.cmake into my own
> CMakeLists.txt, which does not seem very clean.
>
> Can you add a way of
> configuring CPack that allows appending or modifying default values?
> What
> comes to my mind is a semantic like this:
>> include(CPack)
>> set(CPACK_...
> "${CPACK_...} ...")
>> cpack_config()

I think this is an interesting idea.
May be it's worth a feature request on the tracker:
http://public.kitware.com/Bug/my_view_page.php

This would even be better with a patch proposal :-)

My personal point of view with your idea is that
since we most most probably want to maintain backward compatibility
it would even be better if we can do

1 - set(CPACK_...
2 - include(CPack)
3 - set(CPACK_...)
4 - cpack_update_config() or cpack_reconfig()

that way 1, 3 and 4 are optional just as today.
3 and 4 would bring what you suggest.

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

[Eric Noulard]

2010/8/2 David Cole :
> On Sun, Aug 1, 2010 at 6:17 PM, Eric Noulard  wrote:
>>
>> 2010/8/1 Dennis Schridde :
>> > Hello!
>> >
>> > I just started experimenting with CPack. According to the docs and
>> > code it is to be used like this:
>> >> set(CPACK_... ...)
>> >>
>> > include(CPack)
>> >
>> > This, however, does not allow making use of the defaults
>> > present in CPack.cmake. (Most notably CPACK_SOURCE_IGNORE_FILES.)
>> > I had to
>> > copy the default value of that variable out of CPack.cmake into my own
>> > CMakeLists.txt, which does not seem very clean.
>> >
>> > Can you add a way of
>> > configuring CPack that allows appending or modifying default values?
>> > What
>> > comes to my mind is a semantic like this:
>> >> include(CPack)
>> >> set(CPACK_...
>> > "${CPACK_...} ...")
>> >> cpack_config()
>>
>> I think this is an interesting idea.
>> May be it's worth a feature request on the tracker:
>> http://public.kitware.com/Bug/my_view_page.php
>>
>> This would even be better with a patch proposal :-)
>>
>> My personal point of view with your idea is that
>> since we most most probably want to maintain backward compatibility
>> it would even be better if we can do
>>
>> 1 - set(CPACK_...
>> 2 - include(CPack)
>> 3 - set(CPACK_...)
>> 4 - cpack_update_config() or cpack_reconfig()
>>
>> that way 1, 3 and 4 are optional just as today.
>> 3 and 4 would bring what you suggest.
>
>
> You can already do this today with:
> 1 - set(CPACK_...
> 2 - include(CPack)
> 3 - set(CPACK_...)
> 4 - include(CPack)
> Simply including CPack a second time will configure the files according to
> the new values set in step 3. No need for a bug tracker entry, no need to do
> any update or re-config. Simply including CPack a second time will call
> configure_file for the two files of interest: CPackConfig.cmake and
> CPackSourceConfig.cmake...

The second CPack inclusion is not always working as expected
http://public.kitware.com/Bug/view.php?id=10751

most probably because of the "cpack_set_if_not_set" usage inside CPack.cmake

like I said before
set(CPACK_...
include(CPack)

"looks like a function call" but it has several unexpected side effect
because it is not a function call.

To be honest I'm not saying it's not useful as-it-is, it is **not always**
obvious to guess which CPACK_xxx
variables will be taken into account and which won't because of the first
set(CPACK_)


-- 
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] Support for multiple components in cpack

[Eric Noulard]

Hi All,

I did add a patch for the "multiple file problem"
http://public.kitware.com/Bug/view.php?id=10736

May be interested people can have a try and comment
this patch.

It adds the possibility  for any CPack generators to generate multiple file.
It adds "preliminary" support for component to all "Archive Generators"
(ZIP, TGZ, STGZ etc...) as an example of use.

The change is "backward compatible" in the sense that if
all CPack generators (but the archive one) behaves as before
with either componentized  project or not.

Waiting for feedback before going on

-- 
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] Support for multiple components in cpack

[Eric Noulard]

2010/8/2 Clinton Stimpson :
>>
>> Waiting for feedback before going on
>
> So I wondered if we were basically getting 3 modes out of this:
>
> 1. put multiple components in one components aware package (nsis, 
> packagemaker,...).
> 2. put multiple components in one non-component aware package (tar.gz, 
> .zip...).
> 3. put multiple components in multiple packages (all cpack generators).
>
> And how does one choose the behavior they want?

1. or 3. depends on the package capability.
Typically NSIS and PackageMaker may prefer 1. but you cannot do 1. with
DEB or RPM so you have to go with 3.

2. may always be an option because it was the behavior we had before the
component support and ALL CPack generator may handle an all-in-one package.
We could add an OPTION like CPACK_COMPONENT_ALL_IN_ONE which
would basically tell CPack to ignore the component aspect.

3. is an option for any current packages including tar.gz, zip etc...
(and probably even NSIS and PackageMaker).

So I would say that depending on the generator "intrinsic" capabilities
it should (in that order)

chose 2) if CPACK_COMPONENT_ALL_IN_ONE is True
chose 1) if possible
chose 3) if possible
chose 2) as a failover.


-- 
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] Support for multiple components in cpack

[Eric Noulard]

2010/8/3 Dr. Stefan Sablatnög :
> Hi all,
>
> first of all many thanks for considering to provide such a functionality.
> I tried it on an small example yesterday and it worked as expected
> (I patched against cmake 2.8.2), a larger test will follow as soon as I
> find the time.

Ok thanks.
Do not hesitate to give us more feedback when you find the time to do
more extensive tests.
Give your feedback either on the list and/or on the bug tracker:
http://public.kitware.com/Bug/view.php?id=10736

> One minor thing (maybe a different issue?),
> I am not quite sure of yet is how to handle the destination
> of the packages? Is there already way to produce (or copy) the packages
> to a user defined place (we usually put our final deliveries under revision
> control, so it would be ideal if the package would be in the "right" place
> automatically after each build.)

I think this is another issue.
You may already be able to do what you want if you set CPACK_PACKAGE_DIRECTORY

e.g
try cpack -D CPACK_PACKAGE_DIRECTORY=/tmp -G ZIP

if it is not working for you then open a feature request which explain
precisely your need.
-- 
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] Support for multiple components in cpack

[Eric Noulard]

2010/8/3 David Cole :
> On Mon, Aug 2, 2010 at 6:57 PM, Eric Noulard  wrote:

>>
>> 2. may always be an option because it was the behavior we had before the
>> component support and ALL CPack generator may handle an all-in-one
>> package.
>> We could add an OPTION like CPACK_COMPONENT_ALL_IN_ONE which
>> would basically tell CPack to ignore the component aspect.
>
> FYI: there already is an option that's similar to this, I
> think: CPACK_MONOLITHIC_INSTALL
> Does that have the effect you're talking about or are you thinking something
> different?

You are right that's the idea.
I wasn't aware of that option... I'll go for a thorough read of
CPack.cmake documentation
before re-inventing existing options...





-- 
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] Support for multiple components in cpack

[Eric Noulard]

2010/8/3 Eric Noulard :
> 2010/8/3 Dr. Stefan Sablatnög :
>> Hi all,
>>
>> first of all many thanks for considering to provide such a functionality.
>> I tried it on an small example yesterday and it worked as expected
>> (I patched against cmake 2.8.2), a larger test will follow as soon as I
>> find the time.
>
> Ok thanks.
> Do not hesitate to give us more feedback when you find the time to do
> more extensive tests.
> Give your feedback either on the list and/or on the bug tracker:
> http://public.kitware.com/Bug/view.php?id=10736
>
>> One minor thing (maybe a different issue?),
>> I am not quite sure of yet is how to handle the destination
>> of the packages? Is there already way to produce (or copy) the packages
>> to a user defined place (we usually put our final deliveries under revision
>> control, so it would be ideal if the package would be in the "right" place
>> automatically after each build.)
>
> I think this is another issue.
> You may already be able to do what you want if you set CPACK_PACKAGE_DIRECTORY
>
> e.g
> try cpack -D CPACK_PACKAGE_DIRECTORY=/tmp -G ZIP
>
> if it is not working for you then open a feature request which explain
> precisely your need.

Just one more precision.
CPACK_PACKAGE_DIRECTORY is currently used as the root directory
used by CPack to do the packaging (including the creation of the

${CPACK_PACKAGE_DIRECTORY}/_CPack_Packages

hierarchy so if you do use "cpack -D CPACK_PACKAGE_DIRECTORY=/tmp"
the [final] packages will be put in "/tmp" but you will end-up with a
tmp/_CPack_Packages directory too.

If the behavior you want is "only" to have the final packages in "/tmp"
then the current CPACK_PACKAGE_DIRECTORY is not enough
and you should file a feature request which describe what you need/want
precisely.

On way to avoid  the spurious "_CPack_Packages" dir would be add
something like "automatic clean-up" whenever CPACK_PACKAGE_DIRECTORY
is specified on the command line.

Another way would be to add a new CPACK_PACKAGE_DESTINATION option
that if defined with a valid directory path value
would handle the final copy/move of the to this destination.

-- 
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] Support for multiple components in cpack

[Eric Noulard]

2010/8/3 Eric Noulard :
> 2010/8/3 David Cole :
>> On Mon, Aug 2, 2010 at 6:57 PM, Eric Noulard  wrote:
>
>>>
>>> 2. may always be an option because it was the behavior we had before the
>>> component support and ALL CPack generator may handle an all-in-one
>>> package.
>>> We could add an OPTION like CPACK_COMPONENT_ALL_IN_ONE which
>>> would basically tell CPack to ignore the component aspect.
>>
>> FYI: there already is an option that's similar to this, I
>> think: CPACK_MONOLITHIC_INSTALL
>> Does that have the effect you're talking about or are you thinking something
>> different?
>
> You are right that's the idea.
> I wasn't aware of that option... I'll go for a thorough read of
> CPack.cmake documentation
> before re-inventing existing options...

One remark about CPACK_MONOLITHIC_INSTALL, it seems to be taken into
at CMake time
and not at CPack time?

i.e.

cpack -D CPACK_MONOLITHIC_INSTALL=1 NSIS

does not work whereas

cmake -DCPACK_MONOLITHIC_INSTALL=1
+
cpack NSIS

is OK.

is it supposed to work at CMake time only ?

if this is the case my initial idea was to be able to chose at CPack 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] Support for multiple components in cpack

[Eric Noulard]

2010/8/2 Eric Noulard :
> Hi All,
>
> I did add a patch for the "multiple file problem"
> http://public.kitware.com/Bug/view.php?id=10736
>
> May be interested people can have a try and comment
> this patch.
>
> It adds the possibility  for any CPack generators to generate multiple file.
> It adds "preliminary" support for component to all "Archive Generators"
> (ZIP, TGZ, STGZ etc...) as an example of use.
>
> The change is "backward compatible" in the sense that if
> all CPack generators (but the archive one) behaves as before
> with either componentized  project or not.
>
> Waiting for feedback before going on

I did update the patch set on
http://public.kitware.com/Bug/view.php?id=10736

they are more "modular" which may authorize more gradual inclusion to
mainstream.

I need help for testing on Windows and OS X,
because unfortunately I won't be able to test on those platforms.


-- 
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] Double linking / linking static libraries

[Eric Noulard]

2010/8/4 Dennis Schridde :
>
> I am
> using Fedora release 12 and cmake version 2.6-patch 4.
> The issue is not
> reproducible on Gentoo/Linux and cmake version 2.8.1.
>
> Is cmake-2.6 still being maintained?

I don't think so.
I think Bill told that 2.6.4 was the last release for 2.6.x.

> Otherwise I will suggest an update to our admins. (Is
> cmake-2.8 available for Fedora 12?)

Official F12 repo contains 2.6.4
download.fedora.redhat.com/pub/fedora/linux/updates/12/i386/cmake-2.6.4-5.fc12.i686.rpm

Official F13 repo contains 2.8.0
download.fedora.redhat.com/pub/fedora/linux/releases/13/Everything/i386/os/Packages/cmake-2.8.0-2.fc13.i686.rpm

Fedora/RedHat Rawhide contains 2.8.2
download.fedora.redhat.com/pub/fedora/linux/development/rawhide/i386/os/Packages/cmake-2.8.2-2.fc14.i686.rpm

Your sysadmin may probably rebuild a 2.8.2 RPM for F13 using the
RawHide source rpm.

In any case they should be able to build 2.8.2 RPM from CMake 2.8.2
source using CPack RPM.



-- 
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] Building source RPMs?

[Eric Noulard]

2010/8/5 Magnus Therning :
> I'm currently using CPack to build binary RPMs, is there a way to also
> generate a source RPM?

Not yet...with CPackRPM.

Building  a source RPM with CMake/CPack is not as easy as building a
binary RPM. Because currently the spec file used to build a binary RPM
is a "short-cutted" one:
   - the %prep step is a simple move of directory
   - the %build is void (because CMake BUILDTOOL should have already done
 the build
   - the %install is a simple move too (because CPack did the install
on it's own)

This is due to the fact that when you call CPack,
   - CMake has been called
   - The software has been built
   - CPack will call install for you BEFORE calling the CPackRPM generator
   in the end CPackRPM "just" have to package the "already built and
installed file".

In a source RPM you should specify the steps (%prep, %build, %install)
what CMake/CPack usually do.  So basically the RPM spec file to use
for building a source RPM won't be the same as the one used to build
the current binary RPM.

So implementing a "Source RPM" generator is doable,
and in fact it was done in the UseRPMTools.cmake macro
http://www.cmake.org/Wiki/CMakeUserUseRPMTools
which is the ancestor of CPackRPM.

The drawback of the old UseRPMTools is that even for a binary RPM
it will redo all the steps including calling CMake etc...

Why do you need to build a Source RPM with CPack ?
What is your usage pattern?

-- 
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] Building source RPMs?

[Eric Noulard]

2010/8/5 Alexander Neundorf :
> On Thursday 05 August 2010, Magnus Therning wrote:
>> On Thu, Aug 5, 2010 at 10:39, Eric Noulard  wrote:
> ...
>> > What is your usage pattern?
>>
>> We ship most of our sources as source RPMs since most of our changes are
>> added patches to upstream (CentOS) RPMs.
>>
>> It is just nice to also ship the source of our own code as RPMs rather than
>> as tar-ball.  However, I don't see a big problem with simply dropping use
>> of CPack and writing the SPEC files manually.  It would just be a
>> nice-to-have is all.
>
> Somehow I don't really understand how a source RPM or source deb generator
> would make sense for CPack.
> E.g. a source deb is the plain source package, plus an optional patch, plus a
> file which describes how to build it.

Yes a complete RPM spec file which may be used both for binary and source
RPM describes just that, a plain tar file, may be a bunch of patch files, then
some rules to build and install from source
(from the tar which will be automagically patched by rpmbuild).

You are right when you say that it does not make much sense to build
a source RPM with CPack but CPack is able to build a source tarball/zip etc...
CPack is able to build a binary RPM, thus
people expect it can build a source RPM too.

In fact CPack does "part of the job" of any "package build tool" like
the rpm/rpmbuild command or dpkg- commands.

> IMO the patch would be always non-existent if generated with CPack (since this
> generates the package directly from the original source tree),

You can perfectly imagine that you use upstream source tree +
separates patchsets (in Your own source tree)
and use CMake+CPack to build the whoel thing.
It seems to be the case described by Magnus.

However even if the patch set is non-existent it can be useful to have
a source rpm,
but keep reading.

> so the only thing left would be to generate the spec file.

Yes that's true but I think that for many people not writing their spec files
(or deb control data) is of great interest.

> I guess for a source RPM it's similar ?

Yes it is.
The thing is with a source RPM the user (who get the source RPM)
can rebuild a binary rpm using:

rpmbuild --rebuild your.src.rpm

it doesn't have to know whether if the software is using CMake or configure
or whatever to build. All this should be specified in the [source] spec file.

this type of action will
1) unpack the content of the source rpm
2) untar + patch  the sources
3) configure the source for building (may be with cmake or configure)
4) build (make)
5) install (make install)
6) build the binary RPM by packing

So generating a "source spec file" that would be usable to build
a source package is definitely possible. In fact this was done
by the UseRPMTools.cmake
http://www.cmake.org/Wiki/images/9/94/UseRPMTools.cmake
look at ADD_CUSTOM_TARGET(${RPMNAME}_srpm rule.

But again you are right this cpack done with a cpack generator
the rule was only using cpack to build the source tarball.

The main difference between CPack and rpm/deb tools is that CPack
does know the difference between "source" and "binary" package.

The "package_source" rule is "just":

cpack --config CPackSourceConfig.cmake

and the CPackSourceConfig.cmake is using
"CPACK_INSTALLED_DIRECTORIES"
but not
"CPACK_INSTALL_CMAKE_PROJECTS"

whereas  "package" is:

cpack --config CPackConfig.cmake

and CPackConfig.cmake is using
"CPACK_INSTALL_CMAKE_PROJECTS"
and not
"CPACK_INSTALLED_DIRECTORIES"

so you MUST have TWO differents "CPack config file" for describing
how to pack binary or sources. This is not the case for RPM
the spec file (i.e. RPM config file) is/may be the same for source or
binary RPM.

So if you continue to follow me until the end,
it would make sense for CPack to build a source RPM either if
CPack has knowledge that it has to build a source package or
if we write a "separate" generator whose purpose is to build the source package
something like a CPackSRPM.

Would it be worth the needed work to do it, I don't know :-)

-- 
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] Small, complete CPack example?

[Eric Noulard]

2010/8/6 Chris Wolf :
>
> Unfortunately, at first, I din't see how your example is different from
> the parts of my CMakeList.txt I sent in my last post.
>
> Then I noticed that your "install(TARGETS..." command had a relative
> path for "DESTINATION", whereas mine had an absolute path.  When
> I changed to a relative path, it worked...

You should really avoid using absolute path destination for installation.

If you cannot avoid it then you should tell CPack to use DESTDIR
set(CPACK_SET_DESTDIR ON)

however this comes with some trouble too,
see:http://public.kitware.com/Bug/view.php?id=7000


-- 
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] Support for multiple components in cpack

[Eric Noulard]

2010/8/3 Eric Noulard :
> 2010/8/3 David Cole :
>> On Mon, Aug 2, 2010 at 6:57 PM, Eric Noulard  wrote:
>
>>>
>>> 2. may always be an option because it was the behavior we had before the
>>> component support and ALL CPack generator may handle an all-in-one
>>> package.
>>> We could add an OPTION like CPACK_COMPONENT_ALL_IN_ONE which
>>> would basically tell CPack to ignore the component aspect.
>>
>> FYI: there already is an option that's similar to this, I
>> think: CPACK_MONOLITHIC_INSTALL
>> Does that have the effect you're talking about or are you thinking something
>> different?
>
> You are right that's the idea.
> I wasn't aware of that option... I'll go for a thorough read of
> CPack.cmake documentation
> before re-inventing existing options...

After a remark made by Clint and some thought.

CPACK_MONOLITHIC_INSTALL is not covering the whole need
and I think we need a
CPACK_COMPONENTS_ALL_GROUPS_IN_ONE_PACKAGE options.

Have a look at the updated bug entry and the description of
all cases:
http://public.kitware.com/Bug/view.php?id=10736

There is a fifth patch to the current patchset to propose that.

Clint would you be able to give it a try and tell us if with
this last patch (still cumulative) your needs are covered?

-- 
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] Support for multiple components in cpack

[Eric Noulard]

2010/8/4 Kishore :
> On Monday 02 Aug 2010 4:59:47 pm Eric Noulard wrote:
>> Hi All,
>>
>> I did add a patch for the "multiple file problem"
>> http://public.kitware.com/Bug/view.php?id=10736
>>
>> May be interested people can have a try and comment
>> this patch.
>>
>> It adds the possibility  for any CPack generators to generate multiple
>> file. It adds "preliminary" support for component to all "Archive
>> Generators" (ZIP, TGZ, STGZ etc...) as an example of use.
>>
>> The change is "backward compatible" in the sense that if
>> all CPack generators (but the archive one) behaves as before
>> with either componentized  project or not.
>>
>> Waiting for feedback before going on
>
> Thanks. It just tried this and it works as claimed. Later today, i will
> inspect the generated packages on a windows machine too.

Do you have feedback on WIndows?

> Ps: Excited, I tried building a DEB package with this patch thinking that it
> would result in multiple packages. I then reread the post and consoled myself
> that although DEB is also really an archive... the patch does not work on it!

DEB (or RPM) support is not done yet.
I'd like to reach a consensus and approval on ArchiveGenerator before going
on with other generators.

I would accept testing patch 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] Small, complete CPack example?

[Eric Noulard]

2010/8/6 Chris Wolf :
>
> e.g for :  install(TARGETS usb LIBRARY DESTINATION lib)
>
> (where project name is "libusb")
>
> The CPack-generated TGZ archive will contain:
> libusb-0.1.1-Darwin/lib/libusb.dylib
>
> ...this, regardless of the setting of CPACK_INCLUDE_TOPLEVEL_DIRECTORY!
>
> (I would have expected set(CPACK_INCLUDE_TOPLEVEL_DIRECTORY 0)
>  to result in the archive to contain: ./lib/libusb.dylib)

This is the case on my box (Linux Debian Squeeze x86_64),
I can strip off the prefix if I do:

cpack -D CPACK_INCLUDE_TOPLEVEL_DIRECTORY=0 -G TGZ
or
if I set(CPACK_INCLUDE_TOPLEVEL_DIRECTORY 0)

Which version of CMake are you using on which platform?
May be it's a bug.

> Another observation regarding the CPack-generated *.pkg
> (wrapped in a *.dmg) :
>
> The path is prefixed by "./usr", somehow:
>
> (assuming the *.dmg is already mounted)
> $ cd ./libusb-0.1.1-Darwin.pkg/Contents
> $ lsbom -s Archive.bom
> .
> ./usr
> ./usr/lib
> ./usr/lib/libusb.dylib
>
> So where does the "./usr/" prefix come from?

I'm do not know the dmg CPack Generator
(is it PackageMaker or DragNDrop?)
 and I'm not a mac user but each CPack generator has a default
"builtin" CPACK_PACKAGING_INSTALL_PREFIX.

Try
set(CPACK_PACKAGING_INSTALL_PREFIX. "/whatever")


-- 
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 CMAKE_MODULE_PATH in CMakeLists.txt

[Eric Noulard]

2010/8/7 Jashank Jeremy :
> Hi,
>
> I'm working on a project that requires an additional module, which is
> shipped with the project, but I'd like CMake to add CMAKE_SOURCE_PATH
> to CMAKE_MODULE_PATH to pick up the additional module.
>
> I've tried adding
>
> set(CMAKE_MODULE_PATH "${CMAKE_SOURCE_PATH}:${CMAKE_MODULE_PATH}")

LIST(APPEND CMAKE_MODULE_PATH "${CMAKE_SOURCE_PREFIX}")

usually works for me.


>
> to my CMakeLists.txt; this, however, doesn't work. I don't especially
> want developers to have to move the file to a directory on their
> CMAKE_MODULE_PATH, nor do I want to have to get them to set an
> environment variable every time they want to build.
>
> Is there a way around this?

appending CMAKE_MODULE_PATH works for me on several project.
Do not forget to modify CMAKE_MODULE_PATH in the CMakeLists.txt
BEFORE requiring your macro with any

include
find_package
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] Error with cpack -G ZIP

[Eric Noulard]

2010/8/6 Chris Wolf :
> I am trying the ZIP package type and I get the same error on MacOS and Linux:
>
> CPack Error: archive_write_header:Filetype not supportedNo such file or 
> directory -25
> CPack Error: archive_write_data(): tried to write 16384
> write 0
>
>
> I searched around in case this was a known issue.  The Wiki says:
> "Requires zip, WinZip or 7Zip for creating the package."  but I have
> zip on both Mac and Linux.
>
> Any ideas?  Thanks,

The Wiki may not be up to date, CMake switches to libarchive which cannot handle
symlink in ZIP:
http://www.cmake.org/Bug/view.php?id=10162

Do you any symlinks (for library version) in your project.

Could you try TGZ generator in order to see if it's ok?

cpack -G TGZ.


-- 
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] still having a problem with PackageMaker, and now DEB

[Eric Noulard]

2010/8/6 Chris Wolf :
> Earlier, I identified a problem with the "PackageMaker" (Apple) packager,
> and now, I see the same exact problem with the "DEB" (Debian)
> packager - it keeps prefixing "./usr" to all the paths.
>
> Changing CPACK_PACKAGING_INSTALL_PREFIX doesn't do anything
> (even when it's at the top of the file)
>
> This problem does not occur with packagers of type "DragNDrop",
> "TGZ" and "TBZ2" - these are Ok.
>
> Any help would be great, thanks...

Did you try the command line?

cpack -D CPACK_PACKAGING_INSTALL_PREFIX="/opt" -G DEB

it works for me.

if it works for you may be
CPACK_PACKAGING_INSTALL_PREFIX is set to late
in the CMakeLists.txt?

-- 
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] still having a problem with PackageMaker, and now DEB

[Eric Noulard]

2010/8/7 Chris Wolf :
> On 8/6/10 8:55 PM, Eric Noulard wrote:
>>
>> Did you try the command line?
>>
>> cpack -D CPACK_PACKAGING_INSTALL_PREFIX="/opt" -G DEB
>>
>> it works for me.
>>
>> if it works for you may be
>> CPACK_PACKAGING_INSTALL_PREFIX is set to late
>> in the CMakeLists.txt?
>>
>
> Yes, I tried that about 8 hours ago: 
> http://www.cmake.org/pipermail/cmake/2010-August/038785.html
>
> I have to say NOW it's working.  Sorry - I suppose I was changing too many 
> things at one back then
> and I was missing something.
>
> Ok, this issue is resolved, thank you.

Good to know.

[...]
>
> Sorry to beat a "deadhorse", since I see this has already been discussed:
>
> http://www.mail-archive.com/cmake@cmake.org/msg16180.html
>
> I think that guy had a good proposal - being able to control path prefixes
> at a per/generator level.  I guess for now, I can just run cpack multiple
> times with path/generator options on the command line.

I think you are right, command line is the current best way to go.
Now having a Generator Specific
CPACK__PACKAGING_INSTALL_PREFIX
wouldn't be that difficult to implement.

Now when enough [wo]man power will be given in
http://public.kitware.com/Bug/view.php?id=7000
this can be discussed.

Re-read the bug comments and may be add your ideas there.

And I do not think the horse is dead, we are merely waiting
for a jockey for ridding bug #7000 :-)


-- 
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] still having a problem with PackageMaker, and now DEB

[Eric Noulard]

2010/8/7 David Cole :
> Excellent! I am now officially done for the weekend. :-)
> Would you recommend a certain location on the Wiki? i.e. -- were you looking
> someplace for this, and found a place where you think such an explanation
> should go...? I'll be happy to add this to the Wiki, but frequently, I'm not
> sure where to link stuff from. If I knew around where you were looking,
> maybe that would be the right place to link from to get to the new Wiki
> page.
> If you give me a hint about where, I'll add this to the Wiki next week
> sometime.

May I suggest to put such valuable information inside CPack.cmake too,
this way

cmake --help-module CPack

will give the information as well.

I did add a comment on the related "enhance CPack documentation bug":
http://public.kitware.com/Bug/view.php?id=10067


-- 
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] Support for multiple components in cpack

[Eric Noulard]

2010/8/9 Chris Wolf :
>
>
> On 8/9/10 12:11 PM, Kishore wrote:
>> On Friday 06 Aug 2010 4:18:36 am Eric Noulard wrote:
>>> 2010/8/4 Kishore :
>>>> On Monday 02 Aug 2010 4:59:47 pm Eric Noulard wrote:
>>>>> Hi All,
>>>>>
>>>>> I did add a patch for the "multiple file problem"
>>>>> http://public.kitware.com/Bug/view.php?id=10736
>>>>>
>>>>> May be interested people can have a try and comment
>>>>> this patch.
>>>>>
>>>>> It adds the possibility  for any CPack generators to generate multiple
>>>>> file. It adds "preliminary" support for component to all "Archive
>>>>> Generators" (ZIP, TGZ, STGZ etc...) as an example of use.
>>>>>
>>>>> The change is "backward compatible" in the sense that if
>>>>> all CPack generators (but the archive one) behaves as before
>>>>> with either componentized  project or not.
>>>>>
>>>>> Waiting for feedback before going on
>>>>
>>>> Thanks. It just tried this and it works as claimed. Later today, i will
>>>> inspect the generated packages on a windows machine too.
>>>
>>> Do you have feedback on WIndows?
>>
>> I tried this on windows today and it works fine there too! :)
>>
>> While i was with a windows machine, i also noticed that with the NSIS
>> installer, installation of libraries was not forced when applications alone
>> was chosen. Also, i wonder if there is a way to set which components should 
>> be
>> preselected. I guess I should just read the documentation first! :)
>
> I am going to want this on MacOS.  However, on this page:
>
> http://www.itk.org/Wiki/CMake:Component_Install_With_CPack
>
> A remark was added on 18 June, which reads:
>
>    Also, as of the time of this writing, the extensions to CPack
>    required to build component-based installers are only available
>    via CMake CVS.

June yes, but oldish June:  18 June 2008  :-)
Clearly the page needs an update :-)

> My version of CMake is 2.8.2, which I installed via an installer.  Does this 
> mean
> that in order to build a component-based (not monolithic) installer with
> PackageMaker, that I need to checkout CMake and built from source?

Nope,
The PackageMaker seems to already support component installation
but apparently only for MacOS > 10.4:

from the code:
bool cmCPackPackageMakerGenerator::SupportsComponentInstallation() const
{
  return this->PackageCompatibilityVersion >= 10.4;
}

I leave the MacOS oriented support to other people because I didn't my hand
on a Mac for at least a decade :-)
-- 
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] compiling hiphop-php with CMake failed, where is the parameter: EXTRA_LIBS ?

[Eric Noulard]

2010/8/10 a qi :
> HI, ALL
>
> hiphop-php needs cmake to compile,  but I got this error  when  running  make 
> :

May the right place to ask for that would be the  HipHop PHP Mailing list?
http://groups.google.com/group/hiphop-php-dev/?pli=1

--
>
> And  I google "undefined reference to `libiconv_open'",  all the
> answer is    " add   '-liconv'   to   EXTRA_LIBS=...      or
> LDFLAGS=... "  ,  But I can not find  anything about  "EXTRA_LIBS
> or   LDFLAGS"  :
>
>         the follow  command got  nothing.
>         [r...@sys-test-02 hiphop-php]# find . -type f -exec grep
> -Hni  --col "EXTRA_LIBS" {} \;

Because may be this is not the way to do it with CMake.

Now if you look into:

hiphop-php/CMake/HPHPFindLibs.cmake

you'll see that the iconv libs is searched with FIND_LIBRARY (ICONV_LIB iconv)
[only  if on MacOS] then later used for in the custom hphp_link target.

All this is really some specific choice of HipHop PHP developers,
and does not seems CMake specific.

You should ask HipHop PHP 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] CPack Optional Component

[Eric Noulard]

2010/8/10 Vincent LEFORT :
> Hi,
> I come back to know if anyone have an idea of howto do this tricks ?

I think you should have a look at this thread:
http://www.cmake.org/pipermail/cmake/2010-August/038831.html
which explains how to do generator specific things at CPack time.

>> Hello, i use CPack to pack my project.
>>
>> I use components (cpack_add_component) in it, and i do some links in start
>> menu using "set(CPACK_NSIS_MENU_LINKS ...)".
>>
>> But, i want to make the link for example "Documentation" only if the
>> component "Documentation" is checked.

Now if you are talking about "ticking" **at installation time** when
the NSIS installer
is running then I think the best you can do is to customize the NSIS.template.in
with your own logic.

and/or enhance the NSIS generator (i.e. patch it) to suits your needs.

-- 
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] Support for multiple components in cpack

[Eric Noulard]

2010/8/11 Thawan Kooburat :
> Hi Eric,
>
> I read though this thread and also two bug reports related to this issue.
>
> It seems like it will take a while because of CPack design issue. Do
> you think there will be any workaround or small hack to make this work
> with current CPackRPM?

I think it can go faster than you think :-)

The builtin CPack API design issue has just been fixed
and merged to next:
http://cmake.org/gitweb?p=cmake.git;a=log;h=632c2659

So this should end-up in next CMake release.

The redesigned API
let the specific generator decide the number AND the name
of the generated packages.

Now I will rebase my previous patchset for ArchiveGenerators
based on that new API.

Then after that I will tackle the RPM and DEB.

As usual, I cannot ensure any deadlines for those two but if you
want to help you can checkout next and propose some patches
for RPM component support. There shouldn't be any design issue
left now.



-- 
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 build .ax libraries with cmake?

[Eric Noulard]

2010/8/14 Mr Shore :
> Hi all,
>
> The source and binary are available here:
>
> http://tmhare.mvps.org/downloads/vcam.zip
>
> How to build .ax libraries with cmake?

May be some dummy newbie questions but ...

- Can tell us a little about **what are** AX libraries?
- Some documentation? URL ?
- Which tool(s) do you currently use to build those AX ?
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] Relocatable RPM

[Eric Noulard]

2010/8/17 Gerald Hofmann :
> Hi Will,
>
> I found a way to make the RPM relocatable.
>
> This brings some light into rpm relocation: 
> http://www.rpm.org/max-rpm/ch-rpm-reloc.html
>
> The Prefix: tag gives the part of the file names which is replaced when 
> another prefix is specified. You can divert CPACK_RPM_SPEC_MORE_DEFINE from 
> its intended use to add this tag to the spec file.
>
> set( CPACK_RPM_SPEC_MORE_DEFINE "Prefix: /usr" )
>
> The rpm now is relocatable. :-)

I did add [preliminary] built-in support for relocatable RPM:
http://public.kitware.com/Bug/view.php?id=10935

This has been merged to master and should be in next CMake release.
The usage is

set(CPACK_RPM_PACKAGE_RELOCATABLE TRUE)

and CPackRPM will try to build a relocatable package.
This will surely FAIL if:
 - some file are installed with absolute path
 - CPACK_SET_DESTDIR is set to TRUE


> However, I did not yet find a way to set the default prefix from cmake, /usr 
> seems to be hard coded.

You should dig into the ML, there should be some answer about that already :-)
look at this thread:
http://www.cmake.org/pipermail/cmake/2010-August/038820.html

The short answer is many CPack generatorhave builtin prefix (not only CPackRPM)
but those can be overriden by the user if he sets
"CPACK_PACKAGING_INSTALL_PREFIX".
Dave explained how to do it on a per-generator basis:
http://www.cmake.org/pipermail/cmake/2010-August/038831.html

>  Would be nice if someone feels to add another setting to the generator 
> letting the user set the default
> prefix and setting the Prefix: tag at the same time to allow relocation.

Since
http://public.kitware.com/Bug/view.php?id=10935
is fixed this should already be possible.

One last note is as soon as your package is relocatable you can
install it using the
prefix you want with:

rpm --prefix  blah.rpm
or
rpm --relocate blah.rpm


-- 
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] Relocatable RPM

[Eric Noulard]

2010/8/17 Rolf Eike Beer :
> Am Tuesday 17 August 2010 schrieb Eric Noulard:
>
>> set(CPACK_RPM_PACKAGE_RELOCATABLE TRUE)
>>
>> and CPackRPM will try to build a relocatable package.
>> This will surely FAIL if:
>>      - some file are installed with absolute path
>
> Do you mean the packaging will fail or the installation?

**Packaging** will fail. In fact you can make an RPM with CPackRPM
but the generated RPM won't be relocatable.

> When you have a package with a prefix of /opt and relocate it to /usr/local 
> there is usually no
> problem with files e.g. in /etc, they are simply not relocated.

Yes *usually* because when you write an RPM .spec file "by hand" you take
care to specify the fact that those /etc/blah files are %config files and not
just %files.

Currently CPackRPM is not smart enough to do that automatically because

1) It has no clue whether if those files were installed using absolute
path or not
 not mentioning the fact that some if not all those absolute files
are %config files which
 do not need to be relocated.

2) The installation of absolutely installed files **requires** the use
of CPACK_SET_DESDIR flag to ON
 which is not properly handled by CPackRPM yet...
see http://public.kitware.com/Bug/view.php?id=7000

Thoses issues are on my TODO list but I will
   a) finish current work on component packaging
   b) propose a solution for the 7000 bug on DESTDIR (not only for RPM)
   c) then handle fully relocatable RPM

Any volunteer and/or patch are welcomed :-)
-- 
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] Changes from 2.4.8 to 2.6.4

[Eric Noulard]

2010/8/17 Orion Poplawski :
> On 08/17/2010 02:58 PM, Alexander Neundorf wrote:
>>
>> Hi,
>>
>> On Tuesday 17 August 2010, Orion Poplawski wrote:
>>>
>>> I'm contemplating updating the version of cmake in EPEL[1] 5 from 2.4.8
>>> to
>>> 2.6.4
>>
>> Why not go directly to 2.8.2 ?
>> I think there are no known regressions.
>
> Out of my hands.  RHEL6 will ship with 2.6.4 and there needs to be a direct
> upgrade path.

Then may be both can be proposed ?

If you want to avoid the "automatic 2.8" upgrade for "RHEL6"
compatibility reason
then providing an alternative cmake2-8 package may interesting?

CMake 2.6.4 is already more than 1 year old, which may be seen as a stability
advantage but now that 2.8.x is the maintained version providing both 2.6.4 and
2.8.x as an alternative package may be interesting.

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

[Eric Noulard]

2010/8/19 Mr Shore :
> As we know most (old) open source projects are using makefile,
>
> is there a tool to convert makefile to CMakeLists.txt ?

None  I am aware of.

Some converters are listed on the Wiki:
http://www.cmake.org/Wiki/CMake#Converters_from_other_buildsystems_to_CMake

I have some very basic CMakeLists.txt from scratch generator written in python
but I should be near to useless for "real" project.

Is you target project "pure" makefile based or does it use autotools?

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

[Eric Noulard]

2010/8/19 Mr Shore :
> Actually it's not my projects, but the well known projects like MySQL,
> Firefox and so on..

CMakeifying this kind of project may not be an easy task, moreover my own
opinion is that you shoudl ensure that the project stakeholder may be
interested in
this effort.

In fact if they are not interested you may be wasting your time
following the evolution
of the officially supported build system.

I do not think you'll find a useful converter tool for this kind of
project and even if
some tool may do say 80% of the work you'll end up diving in the
current build system
in order to manually do the remaining 20%.

Why would you want to CMakeify Firefox or MySQL?

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

[Eric Noulard]

2010/8/19 Mr Shore :
> Basically, cmake parsor can understand makefile, that's why it can generate
> makefile from CMakeLists.txt,

As far as I know CMake does NOT understand Makefile it does **generates**
makefiles which is totally different story.

Again AFAIK CMake is never **reading** a Makefile.

I invite you to verify my feeling from the CMake source code.

> Just the other way around,why can't it 100% convert a makefile to
> CMakeLists.txt?

Just as with foreign language, because of the semantic.

Usually I am able to say what I want in english without trouble.
But give me some litterature in english to translate back to my
native language and I'll get stuck after 2 pages or 2 lines depending
on the author.


-- 
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] BundleUtilities naming and easing packaging

[Eric Noulard]

2010/8/20 David Cole :
> On Fri, Aug 20, 2010 at 7:37 AM, Mike McQuaid  wrote:
>>
>> Hi,
>>
>> There's been some discussion on
>> http://public.kitware.com/Bug/view.php?id=11126 and I raised the issue about
>> the BundleUtilities port to Windows/Linux: the naming is so bad as to make
>> this (pretty cool) feature completely undiscoverable.

Agreed.
I'm a user of neither BundleUtilities nor GetPrerequisites but
the available documentation are too partial if not cryptic:

BundleUtilities:
"A collection of CMake utility functions useful for dealing with .app
   bundles on the Mac and bundle-like directories on any OS."

May be beginning with an improved doc for those existing
"probably cool" tools would be a good start.

>> I assumed, as I'd think others would, that this would be somehow related
>> to creating .app bundle clones on Linux or Windows, not fixing up the
>> dependencies and installing them. I'd argue that anything relating to the
>> latter really belongs in GetPrerequisites and should be named differently.

GetPrerequisite does not have such a good doc either:
"This script provides functions to list the .dll, .dylib or .so files
   that an executable or shared library file depends on.  (Its
   prerequisites.)"

and then what should we do with that.

All this looks like valuable tools but you cannot get a clear picture
of what they do until you read the content of the corresponding CMake file.

>> For backwards compatibility purposes, obviously the current naming will
>> still need to work but is it possible to get some of this functionality
>> documented and described in a better location?
> Sorry about that. The name was chosen when the functionality was Mac-only,
> then we extended it to cover Windows/Linux. What name would you suggest as
> "more discoverable" or "better"?

May be beginning by enhancing the doc in the header of

BundleUtilities.cmake
GetPrerequisites.cmake

would be a good start which would help us to find better names.

>> Secondly, I'd like to propose a function like "install_prerequisites"
>> which would create all the INSTALL(CODE) stuff for you and call the various
>> needed functions, just to make it easier for people to be able to use
>> bundleutilities/getprerequisites without having to fight with INSTALL(CODE
>> or SCRIPT) problems.
>
> Well, since it needs all the files to exist at analysis time, such a command
> would have to generate code that is run at install time. I'd be surprised if
> you could easily generalize this such that a client project would not have
> to customize it at all, but I could be wrong...
> I'm not a big fan of making all this stuff "too automatic" (which is a
> completely subjective judgment call, but still...) -- because I think it's a
> good thing that developers have to be aware of all the dependencies in their
> code.
> If we make this completely automatic, people will blame CMake when
> they inadvertently pull in some GPL-ed component that they don't really
> *want* to depend on. Pushing the work onto the end-developer has the nice
> side effect of placing the responsibility for such inclusions directly on
> the end-developer. (Which is where it belongs.)

I do totally agree with that, automatic tool sucks when it begans to do things
you wouldn't have done yourself if you were aware of it.
Note however that some packaging tool like rpm or dpkg-xxx already do
such "automatic" dependency analysis on their own in order to fill-in
inter-package dependencies.

I think, may be something that if switched ON that could just WARN
about missing
dependencies in installed things would be good.

This would help the developer to scratch his head in order to figure WHY
he would ever need this GPL-ed thing as a dependency.

May be something like a MODE option to  PULLIN or WARN or ERROR
would be good.

>> Thirdly, I often want to install prerequisites or other files into the
>> packages generated by CPack but not when using make install. It would be
>> good if INSTALL(CODE) or other functions could have an argument to do
>> basically this:
>>  IF( \${CMAKE_INSTALL_PREFIX} MATCHES .*/_CPack_Packages/.* )
>>      <<>>
>>   ENDIF( \${CMAKE_INSTALL_PREFIX} MATCHES .*/_CPack_Packages/.* )
>
> Not a big fan of this one either. Personally, I think it's stupid even to
> have differences between the build tree and the install tree. Now, with
> this, you'd have differences between the "make install" tree and the
> packaged install tree...? Why do you do this? Just to save devs some time at
> "make install" time? Or is there some other valid technical reason that my
> foggy morning brain isn't thinking of...?

Agreed too.
It 'may' be useful to package things which are not installed if they
appear to be handled
at preinstall step of the package installer itself.
For example I may want to build an RPM that would install some dependencies
with the package during %pre step.

If you want to do that you may want a way to specify those
"uninstalled" thing to

Re: [CMake] BundleUtilities naming and easing packaging

[Eric Noulard]

2010/8/20 Mike McQuaid :
>
> On 20 Aug 2010, at 13:09, David Cole wrote:

>
>> Not a big fan of this one either. Personally, I think it's stupid even to 
>> have differences between the build tree and the install tree. Now, with 
>> this, you'd have differences between the "make install" tree and the 
>> packaged install tree...? Why do you do this? Just to save devs some time at 
>> "make install" time? Or is there some other valid technical reason that my 
>> foggy morning brain isn't thinking of...?
>
> I tend to lean towards agreeing with you between install and build time, I 
> think they should be the same. The thing for make install is that there's 
> normally three use-cases here for open-source projects (this makes less sense 
> for proprietary products):
>
> 1) Developer is building and editing code on their machine: in this case they 
> will just use "make" and expect things to work from the build directory (I've 
> filed bugs about this before, being issues with the PATH not being found/set 
> for instance). In this case, the developer will have all the necessary 
> libraries installed on their system.
>
> 2) A user downloads the source (for a tarball or version control) and uses 
> "make install" to build everything and install it to the correct location for 
> their personal use on that machine. In this case, they will have all the 
> necessary libraries already installed and wouldn't expect them to be 
> installed to that prefix.
>
> 3) A developer or user creates a binary package for distribution. In this 
> case, they will have the various libraries already on their system but the 
> end-user of the package won't. As a result, they will want to ensure that 
> these are all distributed.
>
> In short, the difference between 2) and 3) only really matters for 
> open-source projects but is the difference between installing from source or 
> binary packages.

>From your analysis, the "Get Me all dependencies for my binary
package" looks a lot more like a packaging problem
i.e. the CPack job than a building & install problem (CMake job).

Yours script etc... could?should? be handled by CPack itself if I do
something like:

cpack -D CPACK_PACKAGE_EMBBED_PREREQUISITES -G TGZ

this do not change HOW you do it (cmake script can be runned by cpack
etc..) but WHEN you do it?

Why shall I decide in my CMakeLists.txt if I want to build a
"standalone" 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

[CMake] Support for multiple components in cpack (reloaded)

[Eric Noulard]

Hi All,

I finally rebased my previous work on component support for Archive Generators
(i.e. STGZ  TBZ2  TGZ   TZZIP)

(see also ML discussions:
  http://www.cmake.org/pipermail/cmake/2010-July/038575.html
  http://www.cmake.org/pipermail/cmake/2010-August/038663.html
  http://www.cmake.org/pipermail/cmake-developers/2010-August/000413.html)

Up-to-date patches may be retrieved from
 http://public.kitware.com/Bug/view.php?id=10736
or pulled from
 http://github.com/TheErk/CMake/tree/CPackArchiveGenerator-ComponentSupport
 (beware of the fact that this branch has been rebased so
  do not try to update re-pull it from scratch)

I think this work may now be merged in CMake upstream but I need some
final testing.
The implemented features are the following:

1) ALL archive generators (STGZ  TBZ2  TGZ   TZZIP) are now
supporting component install

2) The default behavior is to generate 1 package for each COMPONENT GROUP
(see 
http://paraview.org/Wiki/CMake:Component_Install_With_CPack#Grouping_Components)

3) 3 new CPACK_COMPONENTS var have been introduced:

CPACK_COMPONENTS_ALL_GROUPS_IN_ONE_PACKAGE
CPACK_COMPONENTS_ALL_IN_ONE_PACKAGE
CPACK_COMPONENTS_IGNORE_GROUPS

All those vars may be set at CPack time e.g:
 cpack -D CPACK_COMPONENTS_IGNORE_GROUPS=1 -G ZIP

They change the number and the contents of the generated packages:
3.a) CPACK_COMPONENTS_ALL_GROUPS_IN_ONE_PACKAGE=1
  means you want to get a single package whose content
  is the merge of all components GROUPS

3.b) CPACK_COMPONENTS_ALL_IN_ONE_PACKAGE=1
   means you want to get a single package whose content
   is the merge of all COMPONENTS

 3.c) CPACK_COMPONENTS_IGNORE_GROUPS
   means you want to get 1 package per COMPONENT
   (the default is 1 package per GROUP)

The difference between 3.a) and 3.b) m
CPACK_COMPONENTS_ALL

-- 
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] Support for multiple components in cpack (reloaded)

[Eric Noulard]

2010/8/21 Eric Noulard :
[...]
> They change the number and the contents of the generated packages:
>    3.a) CPACK_COMPONENTS_ALL_GROUPS_IN_ONE_PACKAGE=1
>          means you want to get a single package whose content
>          is the merge of all components GROUPS
>
>    3.b) CPACK_COMPONENTS_ALL_IN_ONE_PACKAGE=1
>           means you want to get a single package whose content
>           is the merge of all COMPONENTS
>
>     3.c) CPACK_COMPONENTS_IGNORE_GROUPS
>           means you want to get 1 package per COMPONENT
>           (the default is 1 package per GROUP)
>

 argh push ENTER too fast...

The difference between 3.a) and 3.b) may not be obvious but
one should know that COMPONENT install will install components
which are specified in CPACK_COMPONENTS_ALL
(component which are not specified there won't be installed at all in any case)
BUT some component may NOT BELONG TO ANY GROUP.

In this case 3.b will include the "orphan" component whereas 3.a will NOT.

last but not least there exist a special component "automatically" generated
by CPack the component is named "Unspecified" and contains all
INSTALLed file/targets/... which do not specify COMPONENT.

If "Unspecified" is contained in CPACK_COMPONENTS_ALL then again
3.b will include the "Unspecified" component whereas 3.a will NOT.

3.c should always include ALL COMPONENTS specified in CPACK_COMPONENTS_ALL.

Note that there is existing feature of CPack which would just make
CPack "ignore" the component stuff this is CPACK_MONOLITHIC_INSTALL.
The CPACK_MONOLITHIC_INSTALL has a different objective because:

* CPACK_MONOLITHIC_INSTALL is used AT CMake time
  whereas 3.a, 3.b and 3.c may be used AT CPack time.
  Thus if you use CPACK_MONOLITHIC_INSTALL all the CPack time
  component stuff will be ignored.

* One other difference is the fact that CPack time component control variable
  may let you package only a chosen portion of the INSTALLed things
  CPACK_MONOLITHIC_INSTALL cannot do that.

Any feedback on this stuff is welcomed.

After that I will go on for RPM and DEB component support which will
be similar but may be more difficult because it has to support
inter-component dependencies which is just not handled at all
for Archive Generators.

-- 
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] Support for multiple components in cpack (reloaded)

[Eric Noulard]

2010/8/22 Rolf Eike Beer :
> Am Saturday 21 August 2010 schrieb Eric Noulard:
>
>> They change the number and the contents of the generated packages:
>>     3.a) CPACK_COMPONENTS_ALL_GROUPS_IN_ONE_PACKAGE=1
>>           means you want to get a single package whose content
>>           is the merge of all components GROUPS
>>
>>     3.b) CPACK_COMPONENTS_ALL_IN_ONE_PACKAGE=1
>>            means you want to get a single package whose content
>>            is the merge of all COMPONENTS
>>
>>      3.c) CPACK_COMPONENTS_IGNORE_GROUPS
>>            means you want to get 1 package per COMPONENT
>>            (the default is 1 package per GROUP)
>
> AFAICS those are exlusive, so why don't you use a single variable with 3
> different values that prints a big fat warning if it is set to anything else 
> to
> make error detection easier?

Yes they are exclusive.
I think the main reason for separate variables is because its "usually" the way
it works with CPack/CMake there are more toggle var 0/1 than switches
values vars.

But this is a good point what do you suggest:

CPACK_COMPONENTS_GROUPING
with possible values:
   ALL_GROUP_IN_ONE
   ALL_COMPONENT_IN_ONE
   IGNORE_GROUP

-- 
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] Support for multiple components in cpack (reloaded)

[Eric Noulard]

2010/8/21 Clinton Stimpson :
>
> I wondered if one would typically use groups if their project contained sub 
> projects, and the sub projects had different conventions for the component 
> names.

I do not usually work with sub-project and I must admit I don't even know
how CPack behave for project with sub-project. I'll try in order to observe
the current behavior.

> Would grouping be a way to overcome that?
> It doesn't seem so, because in the wiki, the nsis example shows a hierarchy 
> of components.
> Or does one just make a common display name for multiple components?

I think component introduction in CPack was meant to bring a mean for:
building a single installer which contains both mandatory and optional part
**in the same package**.

Grouping seem to be there to ease display and "group" selection because
you can tick/untick a group.

Now I think may be you could achieve the same "grouping" effect by using
subproject but:
 1) the devel/runtime grouping does not fall in this category
 2) the component thing is more flexible because you can throw any
 part of your project inside any component whereas using sub-project
 enforce some structural inclusion.

So I think that some sub-project may replace grouping but not all.

-- 
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] Support for multiple components in cpack (reloaded)

[Eric Noulard]

2010/8/22 Eric Noulard :
> 2010/8/22 Rolf Eike Beer :
>> Am Saturday 21 August 2010 schrieb Eric Noulard:
>>
>>> They change the number and the contents of the generated packages:
>>>     3.a) CPACK_COMPONENTS_ALL_GROUPS_IN_ONE_PACKAGE=1
>>>           means you want to get a single package whose content
>>>           is the merge of all components GROUPS
>>>
>>>     3.b) CPACK_COMPONENTS_ALL_IN_ONE_PACKAGE=1
>>>            means you want to get a single package whose content
>>>            is the merge of all COMPONENTS
>>>
>>>      3.c) CPACK_COMPONENTS_IGNORE_GROUPS
>>>            means you want to get 1 package per COMPONENT
>>>            (the default is 1 package per GROUP)
>>
>> AFAICS those are exlusive, so why don't you use a single variable with 3
>> different values that prints a big fat warning if it is set to anything else 
>> to
>> make error detection easier?
>
> Yes they are exclusive.
> I think the main reason for separate variables is because its "usually" the 
> way
> it works with CPack/CMake there are more toggle var 0/1 than switches
> values vars.
>
> But this is a good point what do you suggest:
>
> CPACK_COMPONENTS_GROUPING
> with possible values:
>   ALL_GROUP_IN_ONE
>   ALL_COMPONENT_IN_ONE
>   IGNORE_GROUP

Hi Rolf,

I do update my patchset with your proposal now you can

cpack  -D CPACK_COMPONENTS_GROUPING= -G 

if the  is not recognized you'll get a warning.
the previous 3.a/3.b/3.c variables may be used too.

We may keep them both or decide what is the better way to go after some tests.

The new patch
 0003-CPackArchiveGenerator-improve-usability-and-robustne.patch
is on the bug page:
http://public.kitware.com/Bug/view.php?id=10736

Github repo has been updated too:
http://github.com/TheErk/CMake/tree/CPackArchiveGenerator-ComponentSupport

The patch also fix the case where components are defined but
no component groups are defined, in this case we build 1 package per component
instead of 1 package per group.

-- 
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] Support for multiple components in cpack (reloaded)

[Eric Noulard]

2010/8/22 Eric Noulard :
> 2010/8/21 Clinton Stimpson :
>>
>> I wondered if one would typically use groups if their project contained sub 
>> projects, and the sub projects had different conventions for the component 
>> names.
>
> I do not usually work with sub-project and I must admit I don't even know
> how CPack behave for project with sub-project(s). I'll try in order to observe
> the current behavior.

Ok now I did some testing regarding CPack and subproject(s).
>From my testing and my thinking the conclusion is

CPack is not aware **AT ALL** of subprojects :-(

It's even worse, since CPack is not meant to be included more than once
in the same tree.
In fact you already know that because you are the reporter of this:
http://public.kitware.com/Bug/view.php?id=10751

A related discussion on the ML:
http://www.cmake.org/pipermail/cmake/2010-August/038648.html

So I would say, unless I misunderstood something,
that **currently** you CAN NOT use "subproject" to do any grouping with CPack.
If any subproject do include(CPack) while your toplevel project does
it as well, you'll get unexpected behavior.
The most probable consequence is that is you call "make package" in the toplevel
project you'll get a source package instead of a binary package :-)

What you CAN ALREADY do is to use your toplevel project to build a package which
contains all subprojects. You can even use component in the
subproject(s) it will
work as expected.

If we want to be able to include(CPack) several times, many thing
should be changed
and we should specify the expected behavior very precisely, I do not
think it's as easy
as it may seems. Definitely on my workplan now :-(


-- 
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 invoke 64 bit cmd.exe from cmake script onWindows 7 (x64).

[Eric Noulard]

2010/8/23 Alexander Tarnopolsky :
> Thanks for prompt reply.
>
> In a simple case I invoke just interactive shell using full path to
> 64bit cmd.exe :
>
> file (TO_NATIVE_PATH "$ENV{COMSPEC}" SHELL)
> SET (ARGS /k)
> execute_process (COMMAND ${SHELL} ${ARGS})
>
> Still I see that the cmd process running as 32bit (in TaskManager).

I'm not a windows expert but since execute_process somehow
Fork/CreateThread/CreateProcess from 32 bits CMake I doubt
that this 32bits app may fork a 64bits one.

The converse should be possible because of WoW64 thing
http://en.wikipedia.org/wiki/WoW64.

May be you can try to:

1) open a 32 bits command shell
2) try to open a 64 bits command shell from the first one and see what happen

-- 
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] Support for multiple components in cpack (reloaded)

[Eric Noulard]

2010/8/23 Clinton Stimpson :
> On 08/22/2010 10:47 AM, Eric Noulard wrote:
>>
>> 2010/8/22 Eric Noulard:
>>
>>>
>>> 2010/8/21 Clinton Stimpson:
>>>
>>>>
>>>> I wondered if one would typically use groups if their project contained
>>>> sub projects, and the sub projects had different conventions for the
>>>> component names.
>>>>
>>>
>>> I do not usually work with sub-project and I must admit I don't even know
>>> how CPack behave for project with sub-project(s). I'll try in order to
>>> observe
>>> the current behavior.
>>>
>>
>> Ok now I did some testing regarding CPack and subproject(s).
>>  From my testing and my thinking the conclusion is
>>
>> CPack is not aware **AT ALL** of subprojects :-(
>>
>> It's even worse, since CPack is not meant to be included more than once
>> in the same tree.
>> In fact you already know that because you are the reporter of this:
>> http://public.kitware.com/Bug/view.php?id=10751
>>
>> A related discussion on the ML:
>> http://www.cmake.org/pipermail/cmake/2010-August/038648.html
>>
>> So I would say, unless I misunderstood something,
>> that **currently** you CAN NOT use "subproject" to do any grouping with
>> CPack.
>> If any subproject do include(CPack) while your toplevel project does
>> it as well, you'll get unexpected behavior.
>> The most probable consequence is that is you call "make package" in the
>> toplevel
>> project you'll get a source package instead of a binary package :-)
>>
>> What you CAN ALREADY do is to use your toplevel project to build a package
>> which
>> contains all subprojects. You can even use component in the
>> subproject(s) it will
>> work as expected.
>>
>> If we want to be able to include(CPack) several times, many thing
>> should be changed
>> and we should specify the expected behavior very precisely, I do not
>> think it's as easy
>> as it may seems. Definitely on my workplan now :-(

I may be about to be a little bit disappointing here, but... the previous
phrase contained a typo

"Definitely on my workplan now :-("

 should have been read

"Definitely NOT on my workplan now :-("

thus the not smiling end of the sentence :-(
Sorry about that.

I mean, it would be great to "automagically"  handle subproject
as component, but I think it's not easy.
I'm interested in working on this but NOT NOW :-)

Let's make the current component thing work for ArchiveGenerator,
DEB and RPM and after that we will come back to this
"sub-project as component" topic.

> Yeah, there is that issue, but I'm thinking of something a bit different...
> let me demonstrate with a fictitious example with subprojects:
>
> project A, has sub-projects B, C.
> project B has install() commands with components "Development" and
> "Binaries"
> project C has install() commands with components "Dev" "Runtime"
> And suppose project A has its own naming of components.
>
> now, suppose project A wants to make a component based package, but wants
> B:Development and C:Dev merged together as "Devel," and B:Binaries and
> C:Runtime merged to "Runtime."
>
> Is there anything in cpack to allow for that?  Do we need something like
> that?

Nope nothing I am aware of, CPack cannot "merge" component with different names
you may define a COMPONENT GROUP which contains the differents component.

Like I said before CPack -- is MOSTLY NOT AWARE OF sub-projects --

> I've been getting along fine for a while and I just edit the cmake files of
> my subprojects. I don't know about others though.

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