headers
Alan W. Irwin | 1 Feb 2007 01:24
Picon
Picon

Undocumented magic required for installing globbed files

I naively tried to install some globbed files using, e.g.,

install(
CODE
"file(GLOB USER_DOCS ${CMAKE_SOURCE_DIR}/doc/user/html/*) \n
install(FILES ${USER_DOCS} ${docdir}/html/user/html)"
)

But on Debian stable with cmake-2.4.6, "make install" complains with
the following error message:

CMake Error: Error in cmake code at
/home/software/lasi_svn/HEAD/build_dir/cmake_install.cmake:34:
Command INSTALL not scriptable

Can somebody please document which commands are scriptable and which
are not inside the install command?  For example, is it only the install
command that cannot be nested this way?

Now I have looked at other projects and I inferred from them the following
syntax which works:

install(
   CODE "
   file(GLOB USER_DOCS ${CMAKE_SOURCE_DIR}/doc/user/html/*) \n
   file(INSTALL DESTINATION ${docdir}/html/user/html
   TYPE FILE FILES \${USER_DOCS}
   )"
)
(Continue reading)

Permalink | Reply | 6 comments |
headers
Radu Serban | 1 Feb 2007 02:06

Re: Undocumented magic required for installing globbed files

Alan W. Irwin wrote:

> install(
>   CODE "
>   file(GLOB USER_DOCS ${CMAKE_SOURCE_DIR}/doc/user/html/*) \n
>   file(INSTALL DESTINATION ${docdir}/html/user/html
>   TYPE FILE FILES \${USER_DOCS}
>   )"
> )
[snip]
> Furthermore, I have no clue why the $ in ${USER_DOCS} has to be escaped, 
> but
> the other "$" within the file commands do not.  So all this seems very much
> like magic to me in the absence of documentation.
> 

My guess: If the last $ were not escaped, cmake would attempt to expand it to 
its value in the CMakeLists.txt script (where it is not defined). I assume that 
the INSTALL CODE signature generates a CMake script on the fly which in your 
case will be:

file(GLOB USER_DOCS path_to_sources/doc/user/html/*)
file(INSTALL DESTINATION path_to_docdir/html/user/html
   TYPE FILE FILES ${USER_DOCS})

where path_to_sources is whatever CMAKE_SOURCE_DIR was in your CMakeLists.txt 
(similarly path_to_docdir is whatever ${docdir} was there). Now, if you were to 
run this script, USER_DOCS will contain the proper list of files.

Just out of curiosity, is there any reason/advantage to using the above versus
(Continue reading)

Permalink | Reply | 5 comments |
headers
Alan W. Irwin | 1 Feb 2007 02:42
Picon
Picon

Re: Undocumented magic required for installing globbed files

On 2007-01-31 17:06-0800 Radu Serban wrote:

> Alan W. Irwin wrote:
>
>> install(
>>   CODE "
>>   file(GLOB USER_DOCS ${CMAKE_SOURCE_DIR}/doc/user/html/*) \n
>>   file(INSTALL DESTINATION ${docdir}/html/user/html
>>   TYPE FILE FILES \${USER_DOCS}
>>   )"
>> )
> [snip]
>
> Just out of curiosity, is there any reason/advantage to using the above 
> versus simply having
>
> file(GLOB USER_DOCS ${CMAKE_SOURCE_SIR}/doc/user/html/*)
> file(INSTALL DESTINATION ${docdir}/html/user/html
>  TYPE FILE FILES ${USER_DOCS})

I don't know for sure.

Remember, I just copied a pattern from other projects, and I haven't seen
the alternative pattern you suggest which might or might not work.
Currently, my best guess is "file(INSTALL" is a workhorse that simply copies
files at _cmake_ time.  The purpose of the "install(CODE ..." surrounding
all this is to make a rule that runs cmake commands when the user types
"make install" which, of course, happens at a quite different time than
ordinary cmake commands which are usually used to configure the system before
any make commands are executed.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Radu Serban | 1 Feb 2007 02:49

Re: Undocumented magic required for installing globbed files

Alan W. Irwin wrote:
> On 2007-01-31 17:06-0800 Radu Serban wrote:
> 
>> Alan W. Irwin wrote:
>>
>>> install(
>>>   CODE "
>>>   file(GLOB USER_DOCS ${CMAKE_SOURCE_DIR}/doc/user/html/*) \n
>>>   file(INSTALL DESTINATION ${docdir}/html/user/html
>>>   TYPE FILE FILES \${USER_DOCS}
>>>   )"
>>> )
>> [snip]
>>
>> Just out of curiosity, is there any reason/advantage to using the 
>> above versus simply having
>>
>> file(GLOB USER_DOCS ${CMAKE_SOURCE_SIR}/doc/user/html/*)
>> file(INSTALL DESTINATION ${docdir}/html/user/html
>>  TYPE FILE FILES ${USER_DOCS})
> 
> I don't know for sure.
> 
> Remember, I just copied a pattern from other projects, and I haven't seen
> the alternative pattern you suggest which might or might not work.
> Currently, my best guess is "file(INSTALL" is a workhorse that simply 
> copies
> files at _cmake_ time.  The purpose of the "install(CODE ..." surrounding
> all this is to make a rule that runs cmake commands when the user types
> "make install" which, of course, happens at a quite different time than
(Continue reading)

Permalink | Reply | 3 comments |
headers
Alan W. Irwin | 1 Feb 2007 03:22
Picon
Picon

Re: Undocumented magic required for installing globbed files

On 2007-01-31 17:49-0800 Radu Serban wrote:

> In any case, the alternative I really meant to suggest (which I use in my 
> project) is:
>
> file(GLOB USER_DOCS ${CMAKE_SOURCE_SIR}/doc/user/html/*)
> install(FILES ${USER_DOCS} DESTINATION ${docdir}/html/user/html)
>
> This doesn't use the undocumented file(INSTALL signature and will certainly 
> work as you want.

Sorry, I should have made clear in my original post that the files I was
globbing are generated at "make" time.  Obviously, the first file command
above occurs at configuration time before the files are generated so will
not work for my case.  That is why I have to put the undocumented magic
inside the documented "install(CODE..." signature for my case.

Alan
__________________________
Alan W. Irwin

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

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the
Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jorrit Schaap | 1 Feb 2007 14:52
Favicon

"Configuring" and "Generating" progress indicator

Hi,

We use cmake (on Linux) on a very large source tree (100+ libs, ~50
executables). The "Configuring" and "Generating" steps take a long time,
which is logical and ok. But, would it be possible to print the "Configuring"
and "Generating" progress to the command line? 

I think it should be possible, because the are progress indicators in the
ccmake ui.

Thanks, Jorrit
Permalink | Reply | 0 comments |
headers
David Cole | 1 Feb 2007 15:20
Favicon
Gravatar

Re: Undocumented magic required for installing globbed files

Have you tried the "INSTALL(DIRECTORY" form of the INSTALL command...? Not sure which patch it was introduced in, but it is definitely in 2.4.5 and later...

See "cmake --help-command INSTALL" and read through the DIRECTORY section. I think that's the thing that achieves what you want with the least amount of work on your part.

Or have you tried that already and there's some issue with it...?

HTH,
David


On 1/31/07, Alan W. Irwin < irwin-ICHe1znInSgulI1VNbnaeCwD8/FfD2ys@public.gmane.org> wrote:
On 2007-01-31 17:49-0800 Radu Serban wrote:

> In any case, the alternative I really meant to suggest (which I use in my
> project) is:
>
> file(GLOB USER_DOCS ${CMAKE_SOURCE_SIR}/doc/user/html/*)
> install(FILES ${USER_DOCS} DESTINATION ${docdir}/html/user/html)
>
> This doesn't use the undocumented file(INSTALL signature and will certainly
> work as you want.

Sorry, I should have made clear in my original post that the files I was
globbing are generated at "make" time.  Obviously, the first file command
above occurs at configuration time before the files are generated so will
not work for my case.  That is why I have to put the undocumented magic
inside the documented "install(CODE..." signature for my case.

Alan
__________________________
Alan W. Irwin

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

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package ( plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the
Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project
( lbproject.sf.net).
__________________________

Linux-powered Science
__________________________
_______________________________________________
CMake mailing list
CMake-wChDC6UyXvPYtjvyW6yDsg@public.gmane.org
http://www.cmake.org/mailman/listinfo/cmake

_______________________________________________
CMake mailing list
CMake@...
http://www.cmake.org/mailman/listinfo/cmake
Permalink | Reply | 1 comment |
headers
Jorrit Schaap | 1 Feb 2007 15:59
Favicon

"Configuring" and "Generating" progress indicator

Looking through the cmake sources I found the solution myself. There is some
code commented out in cmakemain.cxx

I submitted it to the bug tracker:
http://www.cmake.org/Bug/bug.php?op=show&bugid=4386

Thanks again, cheers, Jorrit
Permalink | Reply | 0 comments |
headers
Alan W. Irwin | 1 Feb 2007 19:20
Picon
Picon

Re: Undocumented magic required for installing globbed files

On 2007-02-01 09:20-0500 David Cole wrote:

> On 1/31/07, Alan W. Irwin <irwin@...> wrote:
>> Sorry, I should have made clear in my original post that the files I was
>> globbing are generated at "make" time.[...]

> Have you tried the "INSTALL(DIRECTORY" form of the INSTALL command...? Not
> sure which patch it was introduced in, but it is definitely in 2.4.5 and
> later...

Hi David:

Thanks very much for pointing out that powerful new functionality which
exactly solves my problem.  I just quickly checked the release announcements
that Bill sent to this list, and I couldn't find anything related to this
new functionality.  'cmake --help-full' version 2.4.3 does not document this
so it must have been introduced for either 2.4.4 or 2.4.5.

Of course, it is difficult to remember to mention everything new in a
hand-crafted release announcement, but I think it would be a nice idea for
the CMake developers to run a diff between results from old and new 'cmake
--help-full' commands and publish that diff as an automatic part of the
release process.

I just did that for 2.4.6 versus 2.4.3 (using diff --unified=20 to give lots
of context for changes), and the results show the _large_ number of
improvements that have been made to CMake since 2.4.3.  OTOH, 2.4.6 versus
2.4.5 shows no changes to the documentation which indicates 2.4.6 must have
been mostly about bug fixing rather than new core features or new modules
(or new documentation).

Alan
__________________________
Alan W. Irwin

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

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the
Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________
Permalink | Reply | 0 comments |
headers
Omar Souka | 1 Feb 2007 20:19

linking libraries statically

I'm building a shared library that links some external libraries statically.  Something like this:

ADD_LIBRARY(foo SHARED ${SRC})
TARGET_LINK_LIBRARIES(foo
        /a/b/c/abc.a
        /d/e/f/def.a
)

This works fine.  I then have an executable that links to this library

ADD_EXECUTABLE(app ${CODE})
TARGET_LINK_LIBRARIES(app foo)

When the application is linked, it links in the same static libraries as the shared library.  This seems like a bug to link the libraries twice.  Am I doing something wrong?

Thanks,

Omar

_______________________________________________
CMake mailing list
CMake@...
http://www.cmake.org/mailman/listinfo/cmake
Permalink | Reply | 1 comment |

Gmane