Re: [CMake] Compiling fortran

2007-09-26 Thread Alan W. Irwin

On 2007-09-25 22:37-0500 John Doe wrote:


While the cmake man page does not document the proper capitalization of
Fortran for creating a fortran based project, I am now at the point the
compilation does not work for another reason.

Does anyone have an idea what this means?


Clearing dependencies in CMakeFiles/pisces.dir/depend.make.
Clearing dependencies in CMakeFiles/pisces.dir/depend.internal.
/usr/bin/cmake -E cmake_progress_start
/home/anon/svn/svn_repository/relB.9009/pisces/9009/src/CMakeFiles 50
make -f CMakeFiles/Makefile2 all
make[1]: Entering directory
`/home/anon/svn/svn_repository/relB.9009/pisces/9009/src'
make -f CMakeFiles/pisces.dir/build.make CMakeFiles/pisces.dir/depend
make[2]: Entering directory
`/home/anon/svn/svn_repository/relB.9009/pisces/9009/src'
Scanning dependencies of target pisces
cd /home/anon/svn/svn_repository/relB.9009/pisces/9009/src  /usr/bin/cmake
-E cmake_depends Unix Makefiles
/home/anon/svn/svn_repository/relB.9009/pisces/9009/src
/home/anon/svn/svn_repository/relB.9009/pisces/9009/src
/home/anon/svn/svn_repository/relB.9009/pisces/9009/src
/home/anon/svn/svn_repository/relB.9009/pisces/9009/src
/home/anon/svn/svn_repository/relB.9009/pisces/9009/src/CMakeFiles/pisces.dir/DependInfo.cmake
make[2]: Leaving directory
`/home/anon/svn/svn_repository/relB.9009/pisces/9009/src'
make -f CMakeFiles/pisces.dir/build.make CMakeFiles/pisces.dir/requires
make[2]: Entering directory
`/home/anon/svn/svn_repository/relB.9009/pisces/9009/src'
make[2]: *** No rule to make target `new.mod.proxy', needed by
`CMakeFiles/pisces.dir/filopncls.o.requires'.  Stop.
make[2]: Leaving directory
`/home/anon/svn/svn_repository/relB.9009/pisces/9009/src'
make[1]: *** [CMakeFiles/pisces.dir/all] Error 2
make[1]: Leaving directory
`/home/anon/svn/svn_repository/relB.9009/pisces/9009/src'



This appears to be virtually identical to a CMake bug I reported
at http://www.cmake.org/pipermail/cmake/2006-October/011728.html and
also as bug 3984.  The above URL has an ugly workaround for it.  Hope it
works for you as well.

Alan
__
Alan W. Irwin

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

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

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


Re: [CMake] Compiling fortran

2007-09-26 Thread Alin M Elena
On Wednesday 26 September 2007 04:37:33 [EMAIL PROTECTED] wrote:
 While the cmake man page does not document the proper capitalization of
 Fortran for creating a fortran based project, I am now at the point the
 compilation does not work for another reason.

 Does anyone have an idea what this means?


 Clearing dependencies in CMakeFiles/pisces.dir/depend.make.
 Clearing dependencies in CMakeFiles/pisces.dir/depend.internal.
 /usr/bin/cmake -E cmake_progress_start
 /home/anon/svn/svn_repository/relB.9009/pisces/9009/src/CMakeFiles 50
 make -f CMakeFiles/Makefile2 all
 make[1]: Entering directory
 `/home/anon/svn/svn_repository/relB.9009/pisces/9009/src'
 make -f CMakeFiles/pisces.dir/build.make CMakeFiles/pisces.dir/depend
 make[2]: Entering directory
 `/home/anon/svn/svn_repository/relB.9009/pisces/9009/src'
 Scanning dependencies of target pisces
 cd /home/anon/svn/svn_repository/relB.9009/pisces/9009/src 
 /usr/bin/cmake -E cmake_depends Unix Makefiles
 /home/anon/svn/svn_repository/relB.9009/pisces/9009/src
 /home/anon/svn/svn_repository/relB.9009/pisces/9009/src
 /home/anon/svn/svn_repository/relB.9009/pisces/9009/src
 /home/anon/svn/svn_repository/relB.9009/pisces/9009/src
 /home/anon/svn/svn_repository/relB.9009/pisces/9009/src/CMakeFiles/pisces.d
ir/DependInfo.cmake make[2]: Leaving directory
 `/home/anon/svn/svn_repository/relB.9009/pisces/9009/src'
 make -f CMakeFiles/pisces.dir/build.make CMakeFiles/pisces.dir/requires
 make[2]: Entering directory
 `/home/anon/svn/svn_repository/relB.9009/pisces/9009/src'
 make[2]: *** No rule to make target `new.mod.proxy', needed by
 `CMakeFiles/pisces.dir/filopncls.o.requires'.  Stop.
 make[2]: Leaving directory
 `/home/anon/svn/svn_repository/relB.9009/pisces/9009/src'
 make[1]: *** [CMakeFiles/pisces.dir/all] Error 2
 make[1]: Leaving directory
 `/home/anon/svn/svn_repository/relB.9009/pisces/9009/src'

 Thanks,

 Juan

Yap It is a feature of cmake (even there are some bug reports about it). You 
should do (in the root folder of the project, where the CMakeLists.txt 
resides)
touch new.mod.proxy
and the same for any other that complains about.

Alin

-- 

...if the universities will not study useless subjects, who will?
   G. F. Fitzgerald, Nature, 45/46, 392 (1892)
__
Mr. Alin M. ELENA
Atomistic Simulation Centre
School of Mathematics and Physics
Queen's University Belfast
Office: +44 (0)28 9097 1428
Fax: +44 (0)28 9097 5359
http://titus.phy.qub.ac.uk/group/Alin/
[EMAIL PROTECTED]
[EMAIL PROTECTED]
__
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake


Re: [CMake] Question about CMAKE_INSTALL_PREFIX

2007-09-26 Thread Joachim Ziegler

Dizzy wrote:
 So, do you have the target file 
/KM/usr/ziegler/ExGen/cmake/build/src/CMakeFiles/CMakeRelink.dir/startCompletionServer 
?


In src/, I have the target

ADD_EXECUTABLE(startCompletionServer StartCompletionServer.cpp ${BASEFILES})

 If yes do you have write privileges in /usr/local/bin so you can 
write/install files there?


No, I do not have root privileges and I do no want to install something 
into /usr/local. I want to install the target into the bin/ directory of 
the build tree.


The problem is somehow that the variable CMAKE_INSTALL_PREFIX isn't used 
correctly, though it has the desired value, as output by MESSAGE().


Joachim

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


Re: [CMake] Question about CMAKE_INSTALL_PREFIX

2007-09-26 Thread Joachim Ziegler

Dizzy wrote:
In what way it is not used correctly? Do you set it from within 
CMakeLists.txt? Because that doesn't work. You can set it externally with -D 


Yes, in CMakeLists.txt.

to cmake command line tho (similar to how you could give --prefix to 
configure of autoconf).


OK, that works. Thank you!

Joachim

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


Re: [CMake] cmake 2.5 with windows mobile

2007-09-26 Thread Artur Wisz

Hello Alex,

thanks for the help.

Alexander Neundorf wrote:

Why doesn't it work with vcvarsall.bat ?
  

I tried today once again and it does work with vcvarsall.bat.
With -D you are setting cmake variables, so they should have cmake-style 
paths, i.e. using forward slashes. This should fix your problem below.

What do you use TARGET_PLATFORM for ?
  
I have removed the TARGET_PLATFORM for now, it is only used in my cmake 
files and has no significance here.

...
You should use the full path including the drive letter, i.e. 
c:/Programme/.


  
I have corrected the slashes, and got a little bit closer, now I get a 
linking error - there is no parameter to the implib: option and the 
compiler chokes on that.


...
-- Checkpoint7
-- Check for working C compiler: c:/Programme/Microsoft Visual Studio 
8/VC/ce/bin/x86_arm/cl.exe
-- Check for working C compiler: c:/Programme/Microsoft Visual Studio 
8/VC/ce/bin/x86_arm/cl.exe --

broken
CMake Error: The C compiler c:/Programme/Microsoft Visual Studio 
8/VC/ce/bin/x86_arm/cl.exe is not

able to compile a simple test program.
It fails with the following output:
   C:\Programme\Microsoft Visual Studio 8\VC\BIN\nmake.exe -f 
CMakeFiles\cmTryCompileExec.dir
\build.make /nologo -L  
CMakeFiles\cmTryCompileExec.dir\build
   C:\Programme\CMake\bin\cmake.exe -E cmake_progress_report 
C:\work\sw-repo\trunk\osal\build-a

rm-wince-nmake\Debug\CMakeFiles\CMakeTmp\CMakeFiles 1
Building C object CMakeFiles/cmTryCompileExec.dir/testCCompiler.obj
   c:\PROGRA~1\MICROS~3\VC\ce\bin\x86_arm\cl.exe   /nologo /DWIN32 
/D_WINDOWS /D_WIN32_WCE=0x50
1 /D UNDER_CE /D WIN32_PLATFORM_PSPC /D WINCE /D ARM /D _ARM_ /D 
_UNICODE /D UNICODE /fp:fast  /W3 /
Zm1000   /D_DEBUG /MDd /Zi  /Ob0 /Od 
/FoCMakeFiles\cmTryCompileExec.dir\testCCompiler.obj /FdC:\work
\sw-repo\trunk\osal\build-arm-wince-nmake\Debug\CMakeFiles\CMakeTmp\cmTryCompileExec.pdb  
-c C:\work

\sw-repo\trunk\osal\build-arm-wince-nmake\Debug\CMakeFiles\CMakeTmp\testCCompiler.c
testCCompiler.c
Linking C executable cmTryCompileExec
   C:\Programme\CMake\bin\cmake.exe -P 
CMakeFiles\cmTryCompileExec.dir\cmake_clean_target.cmake


   c:\PROGRA~1\MICROS~3\VC\ce\bin\x86_arm\cl.exe  /nologo
/DWIN32 /D_WINDOWS /D_WIN32_WCE=0x
501 /D UNDER_CE /D WIN32_PLATFORM_PSPC /D WINCE /D ARM /D _ARM_ /D 
_UNICODE /D UNICODE /fp:fast  /W3
/Zm1000   /D_DEBUG /MDd /Zi  /Ob0 /Od 
CMakeFiles\cmTryCompileExec.dir\testCCompiler.obj  /FecmTry
CompileExec 
/FdC:\work\sw-repo\trunk\osal\build-arm-wince-nmake\Debug\CMakeFiles\CMakeTmp\cmTryCompi
leExec.pdb -link /implib: /version:0.0   /MANIFEST /machine:THUMB /debug 
/INCREMENTAL:YES /subsystem
:console  coredll.lib corelibc.lib ole32.lib oleaut32.lib uuid.lib 
commctrl.lib

LINK : fatal error LNK1146: no argument specified with option '/implib:'
NMAKE : fatal error U1077: 
'c:\PROGRA~1\MICROS~3\VC\ce\bin\x86_arm\cl.exe' : return code '0x2'

Stop.
NMAKE : fatal error U1077: 'C:\Programme\Microsoft Visual Studio 
8\VC\BIN\nmake.exe' : return code

'0x2'
Stop.

Bye,

Artur

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


Re: [CMake] CPack option naming and deb generator

2007-09-26 Thread Eric Noulard
2007/9/26, Fredrik Hultin [EMAIL PROTECTED]:
 Hi

 I've got a question and/or suggestion regarding CPack:
 How are the generator specific settings supposed to be sent to the generators?

 If I understand the CPack system correctly you're supposed (or at
 least you have the option) to write CPack settings in your
 CMakeLists.txt. This would be achieved by setting up your options with
 SET(CPACK_option value) followed by a INCLUDE(CPack). CMake then
 checks what options are CPack-specific (starts with CPACK_) and places
 them in the file
 CPackConfig.cmake. But how about the generator specific options that
 don't start with CPACK? DEBIAN_PACKAGE_* for example. Wouldn't it be
 better to name all the options for CPack with the prefix CPACK (like
 CPACK_DEBIAN_PACKAGE_ARCHITECTURE or perhaps CPACK_DEB_ARCHITECTURE)?

May be but I think the idea was to let CPACK_xxx apply to generic
generator part while other generator (DEB, ZIP, RPM, ...) would
use  SPECIFIC_PREFIX_PACKAGE_x.

None the less you may define your own value
for DEBIAN_PACKAGE_ARCHITECTURE in your CMakeLists.txt
before INCLUDE(CPack) and your specific value
should be taken into account.
Since CPackDeb.cmake  tells:

# Architecture: (mandatory)
IF(NOT DEBIAN_PACKAGE_ARCHITECTURE)
# There is no such thing as i686 architecture on debian, you should
use i386 instead
# $ dpkg --print-architecture
  SET(DEBIAN_PACKAGE_ARCHITECTURE i386)
ENDIF(NOT DEBIAN_PACKAGE_ARCHITECTURE)


The same is true for RPM.
The idea is the following,

if the users did not defined a specific value in its CMakeLists.txt
then try to define a appropriate one.


 I did a quick modification the deb-generator so that it looked for
 variables named with the CPACK_DEBIAN_PACKAGE prefix instead and my
 settings were indeed transferred from CMakeLists.txt to the
 CPackConfig-file.

The same should be true if you defined:
DEBIAN_PACKAGE_x
vars in your CMakeLists.txt


 I also did a small change to the CPackDeb.cmake file so that it
 defaults to setting the architecture to the current one using dpkg
 --print-architecture rather than simply always setting it to i386
 (Since I'm on AMD64 it mislabeled all my generated .deb-packages).

Mathieu (creator for Deb generator) may answer that.

 If you agree you can have the patches, if you don't; please teach me
 how to do it (ie. selecting DEBIAN_PACKAGE_ARCHITECTURE) the proper
 way. ;)

Try to set the var in your CMakeLists.txt before INCLUDE(CPack)

SET(DEBIAN_PACKAGE_ARCHITECTURE whatever)
INCLUDE(CPack)
-- 
Erk
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake


[CMake] Why are object files built several times?

2007-09-26 Thread Joachim Ziegler

Hello,

I have two targets that have nearly the same sources:

ADD_EXECUTABLE(startCompletionServer StartCompletionServer.cpp ${BASEFILES})
ADD_EXECUTABLE(test-adler32 test-adler32.cpp ${BASEFILES})

I wonder why every object file belonging to the BASEFILES is built 
twice, once for the first target, once again for the second. This 
doubles my compile time!?


Joachim

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


Re: [CMake] Why are object files built several times?

2007-09-26 Thread Dizzy
On Wednesday 26 September 2007 14:55:52 Joachim Ziegler wrote:
 Hello,

 I have two targets that have nearly the same sources:

 ADD_EXECUTABLE(startCompletionServer StartCompletionServer.cpp
 ${BASEFILES}) ADD_EXECUTABLE(test-adler32 test-adler32.cpp ${BASEFILES})

 I wonder why every object file belonging to the BASEFILES is built
 twice, once for the first target, once again for the second. This
 doubles my compile time!?

You will notice that cmake is building files inside a build directory 
different for each target. So it is ment to be that way (normally you may 
have different compile flags for different targets so you want that). If you 
do not want that then just put your BASEFILES in a convenience library and 
reuse it from both targets such as:

add_library(base ${BASEFILES})

add_executable(target1 target1.cpp)
target_link_libraries(target1 base)

add_executable(target2 target2.cpp)
target_link_libraries(target2 base)


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


Re: [CMake] ctest question

2007-09-26 Thread Mathieu MARACHE
2007/9/25, Juan Sanchez [EMAIL PROTECTED]:
 Hi Alan,

 I also have floating point results I want to account for.  I'm thinking
 about writing a diff script for numerical results which uses an absolute
 and relative error tolerance.  This would account for the difference in
 transcendentals and other math functions between processors and math
 libraries.  I always disable 80 bit extended precision on linux since
 the results are non-deterministic with respect to compiler settings.

diff with numerical precision concerns is ndiff :
http://www.math.utah.edu/~beebe/software/ndiff

HTH

 Regards,

 Juan


 Alan W. Irwin wrote:
  On 2007-09-24 10:05-0500 Juan Sanchez wrote:
 
  Hello Alan,
 
  From your example, what in this statement that causes the test to run
  when I type make test?
 
  ADD_TEST(my_first_test diff -q goldenfile testfile)
 
  All it says is to run diff.  How do I tell it to generate the testfile
  from another executable?  How do I tell this executable to run only when
  I type make test and not a moment before?
 
  Hi Juan:
 
  In the above simple example diff is run only when you run ctest (or I
  guess make test although I don't use that). So you could do something like
 
  ADD_TEST(my_first_test ${CMAKE_CURRENT_BINARY_DIR}/create_testfile; diff -q 
  goldenfile testfile)
 
  subject to escaping of ; which I can never get right until I experiment.
  (This general command-line approach of separating commands with ; only
  works on Unix, I believe.)
 
  Then the create_testfile executable is run at ctest time to create testfile
  and then diff is run immediately afterwards (which appears to be what you
  want).
 
  A better approach would be to put everything you want including the diff
  into a configurable script, e.g.,
 
  ADD_TEST(my_first_test ${CMAKE_CURRENT_BINARY_DIR}/test1.sh)
 
  Note, in this case, the script is configured using CONFIGURE_FILE at
  cmake time (basically by substituting CMake-defined variables when needed),
  but run only at ctest time.
 
  Our tests don't use diff (because postscript PLplot results are slightly
  platform/compiler version dependent because of floating-point rounding
  issues), but we do use a configurable scripting approach to generate our
  test plots, see
  http://plplot.svn.sourceforge.net/viewvc/plplot/trunk/test/CMakeLists.txt?view=log
 
  I don't recommend you wade through _all_ of that CMake logic and bash script
  logic since it is so specific to our PLplot needs (and also its pretty
  voluminous/hierarchical since it deals with hundreds of test plots), but I
  have given you the above starting reference in case you have trouble
  configuring test scripts for yourself using CONFIGURE_FILE.
 
  Alan
  __
  Alan W. Irwin
 
  Astronomical research affiliation with Department of Physics and Astronomy,
  University of Victoria (astrowww.phys.uvic.ca).
 
  Programming affiliations with the FreeEOS equation-of-state implementation
  for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
  package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
  Linux Links project (loll.sf.net); and the Linux Brochure Project
  (lbproject.sf.net).
  __
 
  Linux-powered Science
  __
 
 


 --
 Juan Sanchez
 [EMAIL PROTECTED]
 800-538-8450 Ext. 54395
 512-602-4395


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



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


Re: [CMake] ctest question

2007-09-26 Thread Mathieu MARACHE
2007/9/25, Juan Sanchez [EMAIL PROTECTED]:
 Hi Alan,

 I also have floating point results I want to account for.  I'm thinking
 about writing a diff script for numerical results which uses an absolute
 and relative error tolerance.  This would account for the difference in
 transcendentals and other math functions between processors and math
 libraries.  I always disable 80 bit extended precision on linux since
 the results are non-deterministic with respect to compiler settings.

diff with numerical precision concerns is ndiff :
http://www.math.utah.edu/~beebe/software/ndiff

HTH

 Regards,

 Juan


 Alan W. Irwin wrote:
  On 2007-09-24 10:05-0500 Juan Sanchez wrote:
 
  Hello Alan,
 
  From your example, what in this statement that causes the test to run
  when I type make test?
 
  ADD_TEST(my_first_test diff -q goldenfile testfile)
 
  All it says is to run diff.  How do I tell it to generate the testfile
  from another executable?  How do I tell this executable to run only when
  I type make test and not a moment before?
 
  Hi Juan:
 
  In the above simple example diff is run only when you run ctest (or I
  guess make test although I don't use that). So you could do something like
 
  ADD_TEST(my_first_test ${CMAKE_CURRENT_BINARY_DIR}/create_testfile; diff -q 
  goldenfile testfile)
 
  subject to escaping of ; which I can never get right until I experiment.
  (This general command-line approach of separating commands with ; only
  works on Unix, I believe.)
 
  Then the create_testfile executable is run at ctest time to create testfile
  and then diff is run immediately afterwards (which appears to be what you
  want).
 
  A better approach would be to put everything you want including the diff
  into a configurable script, e.g.,
 
  ADD_TEST(my_first_test ${CMAKE_CURRENT_BINARY_DIR}/test1.sh)
 
  Note, in this case, the script is configured using CONFIGURE_FILE at
  cmake time (basically by substituting CMake-defined variables when needed),
  but run only at ctest time.
 
  Our tests don't use diff (because postscript PLplot results are slightly
  platform/compiler version dependent because of floating-point rounding
  issues), but we do use a configurable scripting approach to generate our
  test plots, see
  http://plplot.svn.sourceforge.net/viewvc/plplot/trunk/test/CMakeLists.txt?view=log
 
  I don't recommend you wade through _all_ of that CMake logic and bash script
  logic since it is so specific to our PLplot needs (and also its pretty
  voluminous/hierarchical since it deals with hundreds of test plots), but I
  have given you the above starting reference in case you have trouble
  configuring test scripts for yourself using CONFIGURE_FILE.
 
  Alan
  __
  Alan W. Irwin
 
  Astronomical research affiliation with Department of Physics and Astronomy,
  University of Victoria (astrowww.phys.uvic.ca).
 
  Programming affiliations with the FreeEOS equation-of-state implementation
  for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
  package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
  Linux Links project (loll.sf.net); and the Linux Brochure Project
  (lbproject.sf.net).
  __
 
  Linux-powered Science
  __
 
 


 --
 Juan Sanchez
 [EMAIL PROTECTED]
 800-538-8450 Ext. 54395
 512-602-4395


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



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


Re: [CMake] Why are object files built several times?

2007-09-26 Thread Andreas Pakulat
On 26.09.07 15:13:38, Dizzy wrote:
 On Wednesday 26 September 2007 14:55:52 Joachim Ziegler wrote:
  Hello,
 
  I have two targets that have nearly the same sources:
 
  ADD_EXECUTABLE(startCompletionServer StartCompletionServer.cpp
  ${BASEFILES}) ADD_EXECUTABLE(test-adler32 test-adler32.cpp ${BASEFILES})
 
  I wonder why every object file belonging to the BASEFILES is built
  twice, once for the first target, once again for the second. This
  doubles my compile time!?
 
 You will notice that cmake is building files inside a build directory 
 different for each target. So it is ment to be that way (normally you may 
 have different compile flags for different targets so you want that). If you 
 do not want that then just put your BASEFILES in a convenience library and 
 reuse it from both targets such as:

Note that this creates a static convenience library which is not
portable to some architectures without extra compiler flags (need -fPIC
on amd64 and maybe other 64bit architectures).

Another way is to create a shared lib (and also install that one), but
don't provide headers for the library and don't give it a SOVERSION so
people won't link against it.

Andreas

-- 
A gift of a flower will soon be made to you.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake


Re: [CMake] Why are object files built several times?

2007-09-26 Thread Bill Hoffman

Andreas Pakulat wrote:

On 26.09.07 15:13:38, Dizzy wrote:
  

On Wednesday 26 September 2007 14:55:52 Joachim Ziegler wrote:


Hello,

I have two targets that have nearly the same sources:

ADD_EXECUTABLE(startCompletionServer StartCompletionServer.cpp
${BASEFILES}) ADD_EXECUTABLE(test-adler32 test-adler32.cpp ${BASEFILES})

I wonder why every object file belonging to the BASEFILES is built
twice, once for the first target, once again for the second. This
doubles my compile time!?
  
You will notice that cmake is building files inside a build directory 
different for each target. So it is ment to be that way (normally you may 
have different compile flags for different targets so you want that). If you 
do not want that then just put your BASEFILES in a convenience library and 
reuse it from both targets such as:



Note that this creates a static convenience library which is not
portable to some architectures without extra compiler flags (need -fPIC
on amd64 and maybe other 64bit architectures).

Another way is to create a shared lib (and also install that one), but
don't provide headers for the library and don't give it a SOVERSION so
people won't link against it.
  
For the example given this is very portable.  He is building two 
executables and not two shared libraries.


-Bill

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


Re: [CMake] CPack MacOSX bundle

2007-09-26 Thread Sean McBride
On 9/25/07 12:06 PM, Félix C. Morency said:

I'm trying to create a MacOSX bundle with my application. So far, everything
is working (.dmg generation) except the fact that the application is always
installed in /usr/bin. Is there any way to install it in the application
menu ? I'm far from being a mac expert so I would need help please.

If you want something to be in the application menu, then you need to
make an NSStatusItem, not an application.  Google NSStatusItem.

--

Sean McBride, B. Eng [EMAIL PROTECTED]
Rogue Researchwww.rogue-research.com
Mac Software Developer  Montréal, Québec, Canada


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


[CMake] CMake with MinGW = .def and lib files

2007-09-26 Thread Eric Noulard
Hi All,

I'm using CMake on Windows with a mingw compiler.
I wanted to produce .def (and .lib) files corresponding to my DLL
in order to be enable my user using MSVC to use the DLL
as explained here:
http://www.mingw.org/mingwfaq.shtml#faq-msvcdll

For now I have added line likes this:

ADD_LIBRARY(GHA list-of-sources)

IF (MINGW)
SET_TARGET_PROPERTIES(GHA PROPERTIES LINK_FLAGS
-Wl,--output-def,${LIBRARY_OUTPUT_PATH}/libGHA.def)
INSTALL(FILES ${LIBRARY_OUTPUT_PATH}/libGHA.def
DESTINATION lib)
ENDIF (MINGW)

I have added this for each lib I build which is just a pain
(even if I do not have too much lib)

would'nt it be possible to add such feature globally for all
(shared) libs I create using MinGW?

Does any of you did this before?
If yes How may I do that?
If no is it worth a feature request?

One last question which may be out of cmake subject
Do I need to build the .lib files with MSVC LIB tool or
is there a way to use MSVC directly with .def files?

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


Re: [CMake] Compiling fortran

2007-09-26 Thread Juan Sanchez
It turns out that any word of the word Use or use as a word anywhere in
a comment causes the dependency scanner to use the next token on the
line as a module dependency.

So I changed all the code to use xUse and xuse.

Thanks,

Juan

Alin M Elena wrote:
 On Wednesday 26 September 2007 04:37:33 [EMAIL PROTECTED] wrote:
 While the cmake man page does not document the proper capitalization of
 Fortran for creating a fortran based project, I am now at the point the
 compilation does not work for another reason.

 Does anyone have an idea what this means?


 Clearing dependencies in CMakeFiles/pisces.dir/depend.make.
 Clearing dependencies in CMakeFiles/pisces.dir/depend.internal.
 /usr/bin/cmake -E cmake_progress_start
 /home/anon/svn/svn_repository/relB.9009/pisces/9009/src/CMakeFiles 50
 make -f CMakeFiles/Makefile2 all
 make[1]: Entering directory
 `/home/anon/svn/svn_repository/relB.9009/pisces/9009/src'
 make -f CMakeFiles/pisces.dir/build.make CMakeFiles/pisces.dir/depend
 make[2]: Entering directory
 `/home/anon/svn/svn_repository/relB.9009/pisces/9009/src'
 Scanning dependencies of target pisces
 cd /home/anon/svn/svn_repository/relB.9009/pisces/9009/src 
 /usr/bin/cmake -E cmake_depends Unix Makefiles
 /home/anon/svn/svn_repository/relB.9009/pisces/9009/src
 /home/anon/svn/svn_repository/relB.9009/pisces/9009/src
 /home/anon/svn/svn_repository/relB.9009/pisces/9009/src
 /home/anon/svn/svn_repository/relB.9009/pisces/9009/src
 /home/anon/svn/svn_repository/relB.9009/pisces/9009/src/CMakeFiles/pisces.d
 ir/DependInfo.cmake make[2]: Leaving directory
 `/home/anon/svn/svn_repository/relB.9009/pisces/9009/src'
 make -f CMakeFiles/pisces.dir/build.make CMakeFiles/pisces.dir/requires
 make[2]: Entering directory
 `/home/anon/svn/svn_repository/relB.9009/pisces/9009/src'
 make[2]: *** No rule to make target `new.mod.proxy', needed by
 `CMakeFiles/pisces.dir/filopncls.o.requires'.  Stop.
 make[2]: Leaving directory
 `/home/anon/svn/svn_repository/relB.9009/pisces/9009/src'
 make[1]: *** [CMakeFiles/pisces.dir/all] Error 2
 make[1]: Leaving directory
 `/home/anon/svn/svn_repository/relB.9009/pisces/9009/src'

 Thanks,

 Juan
 
 Yap It is a feature of cmake (even there are some bug reports about it). 
 You 
 should do (in the root folder of the project, where the CMakeLists.txt 
 resides)
 touch new.mod.proxy
 and the same for any other that complains about.
 
 Alin
 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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


Re: [CMake] ctest question

2007-09-26 Thread Juan Sanchez
Awesome.  I love that guys work on bibtex and bibtools.

Juan

Mathieu MARACHE wrote:
 2007/9/25, Juan Sanchez [EMAIL PROTECTED]:
 Hi Alan,

 I also have floating point results I want to account for.  I'm thinking
 about writing a diff script for numerical results which uses an absolute
 and relative error tolerance.  This would account for the difference in
 transcendentals and other math functions between processors and math
 libraries.  I always disable 80 bit extended precision on linux since
 the results are non-deterministic with respect to compiler settings.
 
 diff with numerical precision concerns is ndiff :
 http://www.math.utah.edu/~beebe/software/ndiff
 
 HTH
 
 Regards,

 Juan


 Alan W. Irwin wrote:
 On 2007-09-24 10:05-0500 Juan Sanchez wrote:

 Hello Alan,

 From your example, what in this statement that causes the test to run
 when I type make test?

 ADD_TEST(my_first_test diff -q goldenfile testfile)

 All it says is to run diff.  How do I tell it to generate the testfile
 from another executable?  How do I tell this executable to run only when
 I type make test and not a moment before?
 Hi Juan:

 In the above simple example diff is run only when you run ctest (or I
 guess make test although I don't use that). So you could do something like

 ADD_TEST(my_first_test ${CMAKE_CURRENT_BINARY_DIR}/create_testfile; diff -q 
 goldenfile testfile)

 subject to escaping of ; which I can never get right until I experiment.
 (This general command-line approach of separating commands with ; only
 works on Unix, I believe.)

 Then the create_testfile executable is run at ctest time to create testfile
 and then diff is run immediately afterwards (which appears to be what you
 want).

 A better approach would be to put everything you want including the diff
 into a configurable script, e.g.,

 ADD_TEST(my_first_test ${CMAKE_CURRENT_BINARY_DIR}/test1.sh)

 Note, in this case, the script is configured using CONFIGURE_FILE at
 cmake time (basically by substituting CMake-defined variables when needed),
 but run only at ctest time.

 Our tests don't use diff (because postscript PLplot results are slightly
 platform/compiler version dependent because of floating-point rounding
 issues), but we do use a configurable scripting approach to generate our
 test plots, see
 http://plplot.svn.sourceforge.net/viewvc/plplot/trunk/test/CMakeLists.txt?view=log

 I don't recommend you wade through _all_ of that CMake logic and bash script
 logic since it is so specific to our PLplot needs (and also its pretty
 voluminous/hierarchical since it deals with hundreds of test plots), but I
 have given you the above starting reference in case you have trouble
 configuring test scripts for yourself using CONFIGURE_FILE.

 Alan
 __
 Alan W. Irwin

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

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

 Linux-powered Science
 __



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


Re: [CMake] CPack MacOSX bundle

2007-09-26 Thread Sean McBride
On 9/25/07 12:06 PM, Félix C. Morency said:

I'm trying to create a MacOSX bundle with my application. So far, everything
is working (.dmg generation) except the fact that the application is always
installed in /usr/bin. Is there any way to install it in the application
menu ? I'm far from being a mac expert so I would need help please.

Félix,

Re-reading your post, I'm not sure I understand what you mean.  Could
you elaborate?  What do you mean the application menu?

--

Sean McBride, B. Eng [EMAIL PROTECTED]
Rogue Researchwww.rogue-research.com
Mac Software Developer  Montréal, Québec, Canada


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


Re: [CMake] CPack MacOSX bundle

2007-09-26 Thread Félix C. Morency
Thank you for answering.

I googled the NSStatusItem and I'm not quite sure I understand what you
mean. I guess putting the application in the Finder/Application menu could
be done without modifying the source code ? I want to put a shortcut/the
application to the bundle automaticaly with the installer (.dmg). Of what I
understood of my readings, NSStatusItem is for placing the application in
the status bar. I am really a MacOSX noob so excuse my misunderstanding

Regards,
Félix C. Morency

2007/9/26, Sean McBride [EMAIL PROTECTED]:

 On 9/25/07 12:06 PM, Félix C. Morency said:

 I'm trying to create a MacOSX bundle with my application. So far,
 everything
 is working (.dmg generation) except the fact that the application is
 always
 installed in /usr/bin. Is there any way to install it in the application
 menu ? I'm far from being a mac expert so I would need help please.

 If you want something to be in the application menu, then you need to
 make an NSStatusItem, not an application.  Google NSStatusItem.

 --
 
 Sean McBride, B. Eng [EMAIL PROTECTED]
 Rogue Researchwww.rogue-research.com
 Mac Software Developer  Montréal, Québec, Canada



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

Re: [CMake] CPack MacOSX bundle

2007-09-26 Thread Javier Gonzalez
Sean McBride wrote:
 On 9/25/07 12:06 PM, Félix C. Morency said:

   
 I'm trying to create a MacOSX bundle with my application. So far, everything
 is working (.dmg generation) except the fact that the application is always
 installed in /usr/bin. Is there any way to install it in the application
 menu ? I'm far from being a mac expert so I would need help please.
 

 Félix,

 Re-reading your post, I'm not sure I understand what you mean.  Could
 you elaborate?  What do you mean the application menu?

   

What he wants is to install it in /Applications instead of /usr/bin.
That is where Mac users expect packages to be installed.

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


Re: [CMake] when are variables inherited?

2007-09-26 Thread Sylvain Benner



I still don't understand when variables are inherited by subdirectories.
I see that if I define the variable using cmake -D then it is the same
in all subdirectories. I guess I could use an environment variable.
However, if I do something like:

SET (FINITO_INSTALL_DIR /Users/jgonzalez/financial/finito/trunk CACHE
PATH finito-dir)

it is not inherited by subdirectories. What am I missing

Hello,

Which command do you use for subdirectories ?
Be sure to use ADD_SUBDIRECTORY and not SUBDIRS which is an old command 
left in current release for compatibility purpose.


The behavior of ADD_SUBDIRECTORY is that each CMakeLists.txt added with 
this command inherits from the variables set in the caller CMakeLists.txt.


--Sylvain

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


Re: [CMake] when are variables inherited?

2007-09-26 Thread Sylvain Benner



hah! I see what happened. Obviously, the variable needs to be set
_before_ using ADD_SUBDIRECTORY (oops). For some reason I had it after.
Thanks anyway.

Javier

  

Yes, ADD_SUBDIRECTORY processes immediatly the subdirectory.
Note that inherited variables actually are new variables, so if you 
modify an inherited variable in a subdirectory, the parent variable will 
not be modified in the topdirectory.


--Sylvain

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


Re: [CMake] Compiling fortran

2007-09-26 Thread Juan Sanchez
Hi Bill,

I wouldn't mind taking a stab at it.

It would be easy enough to tell lex to drop any line starting with a
comment character.  Something along the lines of:

^[cC].* {}

There seems to be a line in the lexer that does this, but it doesn't
appear that that the start condition, fixed_fmt, is ever activated.

fixed_fmt^[cC*dD].*\n { return EOSTMT; } /* empty lines */

Do you have any info about how to make submissions and getting the
latest CVS?

Juan



Bill Hoffman wrote:
 Juan Sanchez wrote:
 It turns out that any word of the word Use or use as a word anywhere in
 a comment causes the dependency scanner to use the next token on the
 line as a module dependency.

 So I changed all the code to use xUse and xuse.
   
 The problem is well known, and much talked about.
 The solution is to fix the fortran parser:
 from makefdep90 that is used in CMake.
 
 http://www.cmake.org/pipermail/cmake/2006-September/011072.html
 
 A lex/yacc guru would be best to help out here.   Basically we want
 the fortran parser to ignore all comment lines.  I gave it a try a while
 ago, but did not get it to work.  I suppose a hack solution would be to
 pre-process the files and remove the comments before the parser sees
 it.   If someone does either of those, I would be happy to put it into CVS
 CMake.
 
 -Bill
 


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


Re: [CMake] Compiling fortran

2007-09-26 Thread Bill Hoffman

Juan Sanchez wrote:

It turns out that any word of the word Use or use as a word anywhere in
a comment causes the dependency scanner to use the next token on the
line as a module dependency.

So I changed all the code to use xUse and xuse.
  

The problem is well known, and much talked about.
The solution is to fix the fortran parser:
from makefdep90 that is used in CMake.

http://www.cmake.org/pipermail/cmake/2006-September/011072.html

A lex/yacc guru would be best to help out here.   Basically we want
the fortran parser to ignore all comment lines.  I gave it a try a while
ago, but did not get it to work.  I suppose a hack solution would be to
pre-process the files and remove the comments before the parser sees
it.   If someone does either of those, I would be happy to put it into CVS
CMake.

-Bill

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


Re: [CMake] Compiling fortran

2007-09-26 Thread Bill Hoffman

Juan Sanchez wrote:

Hi Bill,

I wouldn't mind taking a stab at it.

It would be easy enough to tell lex to drop any line starting with a
comment character.  Something along the lines of:

^[cC].* {}

There seems to be a line in the lexer that does this, but it doesn't
appear that that the start condition, fixed_fmt, is ever activated.

fixed_fmt^[cC*dD].*\n { return EOSTMT; } /* empty lines */

Do you have any info about how to make submissions and getting the
latest CVS?
  

Instructions for CVS are here:

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

If you get it working, just attach the patch to CVS CMake to the bug in 
the bug tracker.


-Bill

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


Re: [CMake] generating code from compiled program

2007-09-26 Thread James Bigler
Has anyone any examples of building a compiler (of sorts) and using that 
compiler to generate code then integrated into another CMake target?


Thanks,
James

James Bigler wrote:
I have a program built within CMake that generates some code.  I need 
this generated code to compile some other libraries.  The problem I'm 
having is setting the dependency of the generated source file to its 
compiler.  This is what I have currently:


  # This is the helper compiler
  ADD_EXECUTABLE(ExtractSymbolsFromXML ExtractSymbolsFromXML.cc)
  TARGET_LINK_LIBRARIES(ExtractSymbolsFromXML Dataflow_Network)

  # Get the full path to the ExtractSymbolsFromXML executable
  GET_TARGET_PROPERTY(ExtractSymbolsFromXML_exe ExtractSymbolsFromXML 
${CMAKE_BUILD_TYPE}_LOCATION)
  # Get the path to the executable, so that I can stuff the generated 
file in the same place

  GET_FILENAME_COMPONENT(binary_path ${ExtractSymbolsFromXML_exe} PATH)
  SET(Loader_cc ${binary_path}/Loader.cc)
  SET_SOURCE_FILES_PROPERTIES(
${Loader_cc}
PROPERTIES GENERATED TRUE
)
  ADD_CUSTOM_COMMAND(
OUTPUT ${Loader_cc}
COMMAND ${ExtractSymbolsFromXML_exe} -o ${Loader_cc}
# This is where I get hung up.
MAIN_DEPENDENCY ${ExtractSymbolsFromXML_exe}
COMMENT Generating static loader file: ${Loader_cc}
)

  ADD_LIBRARY(StaticHelper Loader.h ${Loader_cc})

==
I can't seem to get the dependency for ${Loader_cc} right.  Any ideas of 
what I'm doing wrong?


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

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


Re: [CMake] Compiling fortran

2007-09-26 Thread Juan Sanchez
Anyone know what are the valid comment lines in all the Fortran variants?

I know of lines beginning with c, C, or * in the first column.

Juan

Bill Hoffman wrote:
 Juan Sanchez wrote:
 Hi Bill,

 I wouldn't mind taking a stab at it.

 It would be easy enough to tell lex to drop any line starting with a
 comment character.  Something along the lines of:

 ^[cC].* {}

 There seems to be a line in the lexer that does this, but it doesn't
 appear that that the start condition, fixed_fmt, is ever activated.

 fixed_fmt^[cC*dD].*\n { return EOSTMT; } /* empty lines */

 Do you have any info about how to make submissions and getting the
 latest CVS?
   
 Instructions for CVS are here:
 
 http://www.cmake.org/HTML/Download.html#cvs
 
 If you get it working, just attach the patch to CVS CMake to the bug in 
 the bug tracker.
 
 -Bill
 
 
 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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


Re: [CMake] Compiling fortran

2007-09-26 Thread Maik Beckmann
Am Mittwoch, 26. September 2007 17:34:38 schrieb Bill Hoffman:


 A lex/yacc guru would be best to help out here.   Basically we want
 the fortran parser to ignore all comment lines.  I gave it a try a while
 ago, but did not get it to work.  I suppose a hack solution would be to
 pre-process the files and remove the comments before the parser sees
 it.   If someone does either of those, I would be happy to put it into CVS
 CMake.

As you might know I work(ed) on this.  As far as I see the parser issues which 
came up here again is solved my porting the lastest makedepf90 version to 
cmake-2.4.7.  Unfortunately I was not able to continue on this for the last 
two moths.  I will prepare the work I did on the parser and post the code in 
the next week.  


Anyway, I willing to continue to work on the fortran support as soon as I have 
time to do this.  Maybe It makes sense to set up a little wiki page to 
discuss and save information about this issue.


Maik



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


[CMake] CTest and Makefiles

2007-09-26 Thread KSpam
I have a strange problem using CTest with Makefiles.  If I run make test, 
ctest is never called.  If I change the name of the target in the Makefile 
from test to test2 and run make test2, then ctest is called properly.

After changing the target name, make test is still recognized as a valid 
target.  In other words, I do not receive the following error:

make: *** No rule to make target `test'.  Stop.

It seems like make has its own internal test target and it will not use the 
test target from the Makefile.  Does anyone know what is going on here or how 
to fix it?

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


Re: [CMake] CTest and Makefiles

2007-09-26 Thread Juan Sanchez
Would you happen to have a file named test in your binary area?  Make
will see the file and think that the target test is up to date.

A proper gnu makefile would mark the test target as phony.  Looking at
the gnu makefile generated by one of my projects, test is not marked as
phony.

Let me know if this is the issue.

Thanks,

Juan

KSpam wrote:
 I have a strange problem using CTest with Makefiles.  If I run make test, 
 ctest is never called.  If I change the name of the target in the Makefile 
 from test to test2 and run make test2, then ctest is called properly.
 
 After changing the target name, make test is still recognized as a valid 
 target.  In other words, I do not receive the following error:
 
 make: *** No rule to make target `test'.  Stop.
 
 It seems like make has its own internal test target and it will not use the 
 test target from the Makefile.  Does anyone know what is going on here or how 
 to fix it?
 
 Thanks,
 Justin
 ___
 CMake mailing list
 CMake@cmake.org
 http://www.cmake.org/mailman/listinfo/cmake
 
 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


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


Re: [CMake] CTest and Makefiles

2007-09-26 Thread Juan Sanchez
As a followup.  If I touch test, the test no longer runs.  If I add
the PHONY target to the Makefile.  The tests still run.


 ~/bar make test

Running tests...
Start processing tests
Test project /home/juans/bar
  1/  1 Testing foo  Passed

100% tests passed, 0 tests failed out of 1
 ~/bar make test
Running tests...
Start processing tests
Test project /home/juans/bar
  1/  1 Testing foo  Passed

100% tests passed, 0 tests failed out of 1
 ~/bar touch test
 ~/bar make test
 ~/bar

 ~/bar echo .PHONY: test  Makefile

 ~/bar make test
Running tests...
Start processing tests
Test project /home/juans/bar
  1/  1 Testing foo  Passed



Juan Sanchez wrote:
 Would you happen to have a file named test in your binary area?  Make
 will see the file and think that the target test is up to date.
 
 A proper gnu makefile would mark the test target as phony.  Looking at
 the gnu makefile generated by one of my projects, test is not marked as
 phony.
 
 Let me know if this is the issue.
 
 Thanks,
 
 Juan
 
 KSpam wrote:
 I have a strange problem using CTest with Makefiles.  If I run make test, 
 ctest is never called.  If I change the name of the target in the Makefile 
 from test to test2 and run make test2, then ctest is called properly.

 After changing the target name, make test is still recognized as a valid 
 target.  In other words, I do not receive the following error:

 make: *** No rule to make target `test'.  Stop.

 It seems like make has its own internal test target and it will not use the 
 test target from the Makefile.  Does anyone know what is going on here or 
 how 
 to fix it?

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





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


Re: [CMake] CTest and Makefiles

2007-09-26 Thread KSpam
Juan,

Thanks for the tip!  Although I did not have a file named test, I did have a 
directory named test (that contains all of my test projects naturally).  
Marking the test target as phony in the Makefile resolved the issue.

It sounds like this should be fixed in the Makefile generator.  There are 
several other targets that should be marked as phony as well.

Thanks,
Justin

On Wednesday 26 September 2007 09:43:42 Juan Sanchez wrote:
 As a followup.  If I touch test, the test no longer runs.  If I add
 the PHONY target to the Makefile.  The tests still run.


  ~/bar make test

 Running tests...
 Start processing tests
 Test project /home/juans/bar
   1/  1 Testing foo  Passed

 100% tests passed, 0 tests failed out of 1
  ~/bar make test
 Running tests...
 Start processing tests
 Test project /home/juans/bar
   1/  1 Testing foo  Passed

 100% tests passed, 0 tests failed out of 1
  ~/bar touch test
  ~/bar make test
  ~/bar

  ~/bar echo .PHONY: test  Makefile

  ~/bar make test
 Running tests...
 Start processing tests
 Test project /home/juans/bar
   1/  1 Testing foo  Passed

 Juan Sanchez wrote:
  Would you happen to have a file named test in your binary area?  Make
  will see the file and think that the target test is up to date.
 
  A proper gnu makefile would mark the test target as phony.  Looking at
  the gnu makefile generated by one of my projects, test is not marked as
  phony.
 
  Let me know if this is the issue.
 
  Thanks,
 
  Juan
 
  KSpam wrote:
  I have a strange problem using CTest with Makefiles.  If I run make
  test, ctest is never called.  If I change the name of the target in the
  Makefile from test to test2 and run make test2, then ctest is
  called properly.
 
  After changing the target name, make test is still recognized as a
  valid target.  In other words, I do not receive the following error:
 
  make: *** No rule to make target `test'.  Stop.
 
  It seems like make has its own internal test target and it will not use
  the test target from the Makefile.  Does anyone know what is going on
  here or how to fix it?
 
  Thanks,
  Justin
  ___
  CMake mailing list
  CMake@cmake.org
  http://www.cmake.org/mailman/listinfo/cmake

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


Re: [CMake] CTest and Makefiles

2007-09-26 Thread Juan Sanchez
I preemptively filed bug:

http://www.cmake.org/Bug/view.php?id=5785

I didn't know directories could trigger this as well.

Juan


KSpam wrote:
 Juan,
 
 Thanks for the tip!  Although I did not have a file named test, I did have 
 a 
 directory named test (that contains all of my test projects naturally).  
 Marking the test target as phony in the Makefile resolved the issue.
 
 It sounds like this should be fixed in the Makefile generator.  There are 
 several other targets that should be marked as phony as well.
 
 Thanks,
 Justin
 
 On Wednesday 26 September 2007 09:43:42 Juan Sanchez wrote:
 As a followup.  If I touch test, the test no longer runs.  If I add
 the PHONY target to the Makefile.  The tests still run.


  ~/bar make test

 Running tests...
 Start processing tests
 Test project /home/juans/bar
   1/  1 Testing foo  Passed

 100% tests passed, 0 tests failed out of 1
  ~/bar make test
 Running tests...
 Start processing tests
 Test project /home/juans/bar
   1/  1 Testing foo  Passed

 100% tests passed, 0 tests failed out of 1
  ~/bar touch test
  ~/bar make test
  ~/bar

  ~/bar echo .PHONY: test  Makefile

  ~/bar make test
 Running tests...
 Start processing tests
 Test project /home/juans/bar
   1/  1 Testing foo  Passed

 Juan Sanchez wrote:
 Would you happen to have a file named test in your binary area?  Make
 will see the file and think that the target test is up to date.

 A proper gnu makefile would mark the test target as phony.  Looking at
 the gnu makefile generated by one of my projects, test is not marked as
 phony.

 Let me know if this is the issue.

 Thanks,

 Juan

 KSpam wrote:
 I have a strange problem using CTest with Makefiles.  If I run make
 test, ctest is never called.  If I change the name of the target in the
 Makefile from test to test2 and run make test2, then ctest is
 called properly.

 After changing the target name, make test is still recognized as a
 valid target.  In other words, I do not receive the following error:

 make: *** No rule to make target `test'.  Stop.

 It seems like make has its own internal test target and it will not use
 the test target from the Makefile.  Does anyone know what is going on
 here or how to fix it?

 Thanks,
 Justin


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


Re: [CMake] generating code from compiled program

2007-09-26 Thread Andreas Pakulat
On 26.09.07 10:03:08, James Bigler wrote:
 Has anyone any examples of building a compiler (of sorts) and using that 
 compiler to generate code then integrated into another CMake target?

Look at Qt apps that use cmake and dbus. Or any kde application and
KDE's automoc-compiler.

Andreas

-- 
Your depth of comprehension may tend to make you lax in worldly ways.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake


Re: [CMake] generating code from compiled program

2007-09-26 Thread James Bigler

On Sep 26, 2007, at 10:11 AM, Juan Sanchez wrote:


Hello James,

I'm curious why your target name is ExtractSymbolsFromXML, but your
dependency is ${ExtractSymbolsFromXML_exe}.

Shouldn't your dependency be the name of the target?


I tried both, and neither work.


In addition, if you add a custom command, don't you have to have use
add_custom_target as well.

For example:
ADD_CUSTOM_COMMAND(
  OUTPUT main.pdf
  DEPENDS main.ps
  COMMAND ps2pdf
  ARGSmain.ps
)

ADD_CUSTOM_TARGET( Docs ALL
  DEPENDS main.pdf
)


I thought that by having the generated source file be a dependency on  
a library it would pull it in:


ADD_CUSTOM_COMMAND(
  OUTPUT mysource.cc
  ...
  )

ADD_LIBRARY(mylib mysource.cc)

I'll try and play around with ADD_CUSTOM_TARGET, but I hate how it  
always seems to run (though I may have been using it wrong).


James



James Bigler wrote:
Has anyone any examples of building a compiler (of sorts) and  
using that

compiler to generate code then integrated into another CMake target?

Thanks,
James

James Bigler wrote:
I have a program built within CMake that generates some code.  I  
need
this generated code to compile some other libraries.  The problem  
I'm

having is setting the dependency of the generated source file to its
compiler.  This is what I have currently:

  # This is the helper compiler
  ADD_EXECUTABLE(ExtractSymbolsFromXML ExtractSymbolsFromXML.cc)
  TARGET_LINK_LIBRARIES(ExtractSymbolsFromXML Dataflow_Network)

  # Get the full path to the ExtractSymbolsFromXML executable
  GET_TARGET_PROPERTY(ExtractSymbolsFromXML_exe  
ExtractSymbolsFromXML

${CMAKE_BUILD_TYPE}_LOCATION)
  # Get the path to the executable, so that I can stuff the  
generated

file in the same place
  GET_FILENAME_COMPONENT(binary_path ${ExtractSymbolsFromXML_exe}  
PATH)

  SET(Loader_cc ${binary_path}/Loader.cc)
  SET_SOURCE_FILES_PROPERTIES(
${Loader_cc}
PROPERTIES GENERATED TRUE
)
  ADD_CUSTOM_COMMAND(
OUTPUT ${Loader_cc}
COMMAND ${ExtractSymbolsFromXML_exe} -o ${Loader_cc}
# This is where I get hung up.
MAIN_DEPENDENCY ${ExtractSymbolsFromXML_exe}
COMMENT Generating static loader file: ${Loader_cc}
)

  ADD_LIBRARY(StaticHelper Loader.h ${Loader_cc})

==
I can't seem to get the dependency for ${Loader_cc} right.  Any  
ideas of

what I'm doing wrong?

Thanks,
James


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


Re: [CMake] generating code from compiled program

2007-09-26 Thread James Bigler

On Sep 26, 2007, at 11:03 AM, Andreas Pakulat wrote:


On 26.09.07 10:03:08, James Bigler wrote:
Has anyone any examples of building a compiler (of sorts) and  
using that

compiler to generate code then integrated into another CMake target?


Look at Qt apps that use cmake and dbus. Or any kde application and
KDE's automoc-compiler.


Is this part of CMake or KDE?  Where can I find an example of this?

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


Re: [CMake] Compiling fortran

2007-09-26 Thread Bill Hoffman

Maik Beckmann wrote:

Am Mittwoch, 26. September 2007 17:34:38 schrieb Bill Hoffman:

  

A lex/yacc guru would be best to help out here.   Basically we want
the fortran parser to ignore all comment lines.  I gave it a try a while
ago, but did not get it to work.  I suppose a hack solution would be to
pre-process the files and remove the comments before the parser sees
it.   If someone does either of those, I would be happy to put it into CVS
CMake.



As you might know I work(ed) on this.  As far as I see the parser issues which 
came up here again is solved my porting the lastest makedepf90 version to 
cmake-2.4.7.  Unfortunately I was not able to continue on this for the last 
two moths.  I will prepare the work I did on the parser and post the code in 
the next week.  



Anyway, I willing to continue to work on the fortran support as soon as I have 
time to do this.  Maybe It makes sense to set up a little wiki page to 
discuss and save information about this issue.
  
So, if we upgrade the makedepf90 the problem is fixed?  That should be 
easy to do.  
I did not see mention of that problem in the release notes for makedepf90. 


-Bill

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


Re: [CMake] generating code from compiled program

2007-09-26 Thread Andreas Pakulat
On 26.09.07 11:25:21, James Bigler wrote:
 On Sep 26, 2007, at 11:03 AM, Andreas Pakulat wrote:
 
 On 26.09.07 10:03:08, James Bigler wrote:
 Has anyone any examples of building a compiler (of sorts) and using that
 compiler to generate code then integrated into another CMake target?
 
 Look at Qt apps that use cmake and dbus. Or any kde application and
 KDE's automoc-compiler.
 
 Is this part of CMake or KDE?  Where can I find an example of this?

FindQt4.cmake is part of CMake's modules and it contains a macro for
generating c++ code from an xml dbus file.

As far as kde-automoc goes its part of KDE4's cmake stuff, available
from 

svn://anonsvn.kde.org/home/kde/trunk/KDE/kdelibs

Andreas

-- 
Give your very best today.  Heaven knows it's little enough.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake


Re: [CMake] generating code from compiled program

2007-09-26 Thread Bill Hoffman

Andreas Pakulat wrote:




On 26.09.07 10:03:08, James Bigler wrote:
  

Has anyone any examples of building a compiler (of sorts) and using that
compiler to generate code then integrated into another CMake target

Does this help:

http://www.cmake.org/Wiki/CMake_FAQ
See :How can I generate a source file during the build?

-Bill

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


Re: [CMake] generating code from compiled program

2007-09-26 Thread James Bigler

Bill Hoffman wrote:

Andreas Pakulat wrote:


   

On 26.09.07 10:03:08, James Bigler wrote:
 
Has anyone any examples of building a compiler (of sorts) and using 
that

compiler to generate code then integrated into another CMake target

Does this help:

http://www.cmake.org/Wiki/CMake_FAQ
See :How can I generate a source file during the build?


I just realized that my problem might be related to a circular dependency I 
hadn't noticed before.  It was reported by make as compiler depends on 
compiler which didn't make sense to me.


ADD_LIBRARY(lib_a ${source_files})
ADD_TARGET_LIBRARY(lib_a lib_helper)

ADD_EXECUTABLE(compiler compiler.cc)
ADD_TARGET_LIBRARY(compiler lib_a)

GET_TARGET_PROPERTY(compiler_location compiler ${CMAKE_BUILD_TYPE}_LOCATION)
ADD_CUSTOM_COMMAND(
  OUTPUT source.cc
  COMMAND ${compiler_location} -o source.cc
  DEPENDS compiler
  )

ADD_LIBRARY(lib_helper source.cc)

=
Here's the dependency chain:

lib_helper - source.cc
source.cc  - compiler
compiler   - lib_a
lib_a  - lib_helper   Circular dependency :(

I'll need to refactor some code before I can address this again.  I'm hoping 
that once I do this, all will become well in the world.  If I still have 
problems, once I remove the circular dependency, I'll come asking again.


Thanks for everyone's suggestions and help!  This is why I like the CMake 
mailing list so much.


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


[CMake] include directories variable?

2007-09-26 Thread Juan Sanchez
How do I get the INCLUDE_DIRECTORIES path?  I need to feed into into the
search path for the swig command line.

Thanks,

Juan


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


[CMake] Project Grouping in a solution

2007-09-26 Thread Neal Meyer
Is there a way to group projects in a solution? Something like this would be
handy

CMakeProject
 -- ALL_BUILD
 -- ZERO_CHECK
 etc
lib
-- lib1
-- lib2

Possibly something that follows the file system setup.

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

[CMake] Passing lists to macros

2007-09-26 Thread Neal Meyer
I've got the following in my CMakeLists.txt

SET( L1 *.h *.hpp *.cpp *.c )
MESSAGE( STATUS L1 = ${L1} )

macro( test L2 )
MESSAGE( STATUS L2 = ${L2} )
FOREACH( L ${L2} )
 MESSAGE( STATUS  L = ${L} )
 SET( L_LIST ${L_LIST} stuff/${L} )
ENDFOREACH( L )
MESSAGE( STATUS L_LIST = ${L_LIST} )
endmacro( test )
test( ${L1} )

I get the following output

-- L1 = *.h;*.hpp;*.cpp;*.c
-- L2 = *.h
--  L = *.h
-- L_LIST =  stuff/*.h

I'm expecting

-- L1 = *.h;*.hpp;*.cpp;*.c
-- L2 = *.h;*.hpp;*.cpp;*.c
--  L = *.h
--  L = *.hpp
--  L = *.cpp
--  L = *.c
--  L_LIST = stuff/*.h stuff/*.hpp stuff/*.cpp stuff/*.c

Can anybody help with this?
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Passing lists to macros

2007-09-26 Thread David Cole
Try:
test(${L1})

You are passing multiple arguments to the macro by using ${L1} without
double quotes (because it expands to a list with multiple elements). Using
double quotes makes it all go into the first macro argument...

Alternatively, you could look up the help for MACRO using:
cmake --help-command MACRO

and read up on using ARGN as a list of arguments past the formal macro
arguments...


HTH,
David


On 9/26/07, Neal Meyer [EMAIL PROTECTED] wrote:


 I've got the following in my CMakeLists.txt

 SET( L1 *.h *.hpp *.cpp *.c )
 MESSAGE( STATUS L1 = ${L1} )

 macro( test L2 )
 MESSAGE( STATUS L2 = ${L2} )
 FOREACH( L ${L2} )
  MESSAGE( STATUS  L = ${L} )
  SET( L_LIST ${L_LIST} stuff/${L} )
 ENDFOREACH( L )
 MESSAGE( STATUS L_LIST = ${L_LIST} )
 endmacro( test )
 test( ${L1} )

 I get the following output

 -- L1 = *.h;*.hpp;*.cpp;*.c
 -- L2 = *.h
 --  L = *.h
 -- L_LIST =  stuff/*.h

 I'm expecting

 -- L1 = *.h;*.hpp;*.cpp;*.c
 -- L2 = *.h;*.hpp;*.cpp;*.c
 --  L = *.h
 --  L = *.hpp
 --  L = *.cpp
 --  L = *.c
 --  L_LIST = stuff/*.h stuff/*.hpp stuff/*.cpp stuff/*.c

 Can anybody help with this?



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

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

[CMake] Interresting dependency problem

2007-09-26 Thread Félix C. Morency
Hi,

I have a particular situation that I would like you to analyze to help me
find the best solution possible.

I have a project A, a project B and an external dependency called C.
The project B depends directly on C.
The project A needs the projects B to build but does not want to know
about its dependencies (C).

So, A--B--C and A doesn't know anything about C.

Of what I tought, there are two solution approaches to this problem:

1. The project A and B cmake script are completly independant; B is
able to build itself alone and A simply include B's script that contains
the link to the dependency C.
2. There is a master script that knows every dependencies (in our case, C)
and which build A and B calling the subdir command to execute their
proper scripts. A and B script knows nothing about C in their proper
scripts.

I did some tests and the second solution is working fine with CMake. Every
depencies are propagated in the three like a charm. However, I have problem
with the first one and I would like if it would be possible to acheive. The
problem is when I include the B script, the CMake engine is searching for
the B files in the A paths. Example:

A source directory is: src/file1.cpp
B source directory is: src/file2.cpp

file2.cpp is searched in the src/ directory of project A. Of course, the
file isn't found and CMake is generating an error.

Here's come the questions:

1. What solution do you think is the best: A main master script that knows
every dependencies of every projects VS Completly indenpendant build
script that we could simply include if we need them and their dependencies
? Please justify.
2. How can I achieve the first solution with CMake ? (Is it possible ?)
3: Is there any better solution that I don't see ?

I would really like to know what you think about this problematic.

Regard,
Félix C. Morency
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake