[CMake] CTEST_UPDATE for clearcase
Hi, CTEST_UPDATE doesn't officialy operate on ClearCase views, but would it be difficult to add support to CTEST_UPDATE just collecting config spec contents and sending it to CDash with subsequent CTEST_SUBMIT command ? Is Update.xml capable of containing such information as ClearCase config spec ? I suppose CDash would require changes as well ? With best regards, Wojtek -- Czy wiesz ile wydasz na własny dom? Sprawdź największą bazę ogłoszeń http://linkint.pl/f2889 ___ 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] Simultaneous --build-and-test and CDash submission
You can do it all in one step with ctest, but you have to write a ctest -S script, and call that... Inside it, you can do a configure from scratch using the ctest_configure(...) command. Then you'll see all the configure output submitted to the dashboard. Poke around the wiki and the mailing list for ctest -S script documentation. (Go with a new style script that uses the commands 'ctest_configure' and 'ctest_build' and 'ctest_test'.) Maybe somebody else has time to chime in and give you more details. Cheers, David Thanks fot hints - I finally managed to make it work using ctest scripting. Basic setup was quite easy, but for a longer while I coudn't find a way to have the BuildName and Site name being set - instead they were void. This resulted in having separate entries being shown in CDash for all three stages: configure, build and test. As suggested by wiki entries I tried playing with setting initial cache but it did not work. After few hours I found out that I need to set variables CTEST_BUILD_NAME and CTEST_SITE in the CTestConfig.cmake file. Once I did that the CDash entries were non-void and the submissions were merged together. With CTest -S working now I have a system with subprojects, and with labels not assigned as subprojects as well, what by the means of filtering feature gives me a very nice possibility to browse submissions by labels, something I asked about in one of my recent posts. Thanks, Wojtek -- Szukasz pracy? Możemy Ci ją dać! Sprawdź http://linkint.pl/f288d ___ 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] Simultaneous --build-and-test and CDash submission
Hi,
I have unit tests configured for CDash submissions. Submissions do work if I
issue in sequence TWO commands which go pretty much like this:
# configure the build system
${CMAKE_ROOT}${CMAKE_BINDIR}/cmake .
# build tests
make clean ; make
# run tests
${CMAKE_ROOT}${CMAKE_BINDIR}/ctest
However, when doing that CDash shows useful results only for the test phase -
build info is missing and configure info shows only 3 lines despite removal of
CMakeCache.txt.
So I attepmted using the build-and-test option. I would expect this to work:
/vob/tetra/tools/CMake/bin_linux_x86_64/ctest -D Experimental --build-and-test
. . --build-generator 'Unix Makefiles' --build-makeprogram `which clearmake`
but it only builds and tests --- '-D' option seems to be ignored.
I also tried this:
/vob/tetra/tools/CMake/bin_linux_x86_64/ctest --build-and-test . .
--build-generator 'Unix Makefiles' --build-makeprogram `which clearmake`
--test-command ./test_command.sh
where test_command.sh executes 'ctest -D Experimental' but although it
submission is achieved the CDash contents is the same as with the original two
commands.
So my question is how to achieve CDash submission with 'scratch' configure info
(just as if cmake was invoked on clean environment), build info (compilation
warnings and such) and test results by issueing single command ?
Thanks for help,
Wojtek
--
Księgowa radzi: Jak załozyć firmę w 15 minut?
http://linkint.pl/f2842
___
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] Simultaneous --build-and-test and CDash submission
So my question is how to achieve CDash submission with 'scratch' configure info (just as if cmake was invoked on clean environment), build info (compilation warnings and such) and test results by issueing single command ? Thanks for help, Wojtek Hi Wojtek, If I understand you correctly, then you would in fact like to run ctest without cmake. You can do that, be you'll need some plumbing (i.e. a small ctest-script) to get ctest going. I think you'll find http://www.cmake.org/Wiki/CTest:Using_CTEST_and_CDASH_without_CMAKE useful. Hope this helps, Marcel Loose. I don't have anything against calling cmake along the way - I just hoped ctest can take care of that by itself allowing just single ctest invocation. Wojtek -- Zasypalo Twoje miasto? Zobacz zdjecia http://linkint.pl/f289f ___ 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] Simultaneous --build-and-test and CDash submission
Użytkownik napisał(a):
From:
Subject: Re: [CMake] Simultaneous --build-and-test and CDash submission
To: Wojciech Migda ;
On Thu, Dec 9, 2010 at 4:13 AM, Wojciech Migda wrote:
Hi,
I have unit tests configured for CDash submissions. Submissions do work if
I issue in sequence TWO commands which go pretty much like this:
# configure the build system
${CMAKE_ROOT}${CMAKE_BINDIR}/cmake .
# build tests
make clean ; make
# run tests
${CMAKE_ROOT}${CMAKE_BINDIR}/ctest
However, when doing that CDash shows useful results only for the test phase
- build info is missing and configure info shows only 3 lines despite
removal of CMakeCache.txt.
So I attepmted using the build-and-test option. I would expect this to work:
/vob/tetra/tools/CMake/bin_linux_x86_64/ctest -D Experimental
--build-and-test . . --build-generator 'Unix Makefiles' --build-makeprogram
`which clearmake`
but it only builds and tests --- '-D' option seems to be ignored.
I also tried this:
/vob/tetra/tools/CMake/bin_linux_x86_64/ctest --build-and-test . .
--build-generator 'Unix Makefiles' --build-makeprogram `which clearmake`
--test-command ./test_command.sh
where test_command.sh executes 'ctest -D Experimental' but although it
submission is achieved the CDash contents is the same as with the original
two commands.
So my question is how to achieve CDash submission with 'scratch' configure
info (just as if cmake was invoked on clean environment), build info
(compilation warnings and such) and test results by issueing single command
?
Thanks for help,
Wojtek
--
Księgowa radzi: Jak załozyć firmę w 15 minut?
http://linkint.pl/f2842
___
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
How about this?
# configure the build system
${CMAKE_ROOT}${CMAKE_BINDIR}/cmake .
# run an Experimental dashboard
${CMAKE_ROOT}${CMAKE_BINDIR}/ctest -D Experimental
Running an Experimental dashboard should execute configure, build and
test steps and submit the results to the CDash server. The initial
configure is necessary to configure some of the files that ctest reads
to know, for example, where the CDash server is.
HTH,
David
Thank you David - I got the compilation warnings to appear in the CDash listing.
In addition, can sth be done with the Configure Output ? In CDash it goes like
this (all 3 lines):
-- Configuring done
-- Generating done
-- Build files have been written to: foo_location
whilst I'd like to have it in full, like when CMake is initially invoked, e.g:
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check if the system is big endian
-- Searching 16 bit integer
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
... snip
Thanks,
Wojtek
---
Nadal nie wiesz, co wybrac na prezent?
Sprawdz nasz poradnik http://linkint.pl/f2885
http://linkint.pl/f2885
___
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] General LABELS questions
Hi,
I'm trying to get LABELS/Subprojects working, having read this
http://www.kitware.com/blog/home/post/11 and this
http://www.kitware.com/blog/home/post/11
1. It is unclear to me whether to have LABELS working I must use CTest script
(-S) or I can achieve that simply by editing of CMakeLists.txt,
CTestConfig.cmake, CTestCustom.cmake.
2. Once I get LABELS working is it possible to browse results in CDash by
LABEL, e.g. see all submissions with given label attached, but not having
SubProject named after LABEL ?
I've reached a point where in the tests summary CDash shows expected label
along each testcase, e.g:
Name;Status;Time (s);Labels
foo_test;Passed;0.01;MY_LABEL
However, in the Experimental submissions section Labels column in empty: (none).
Same with Subproject created with a name MY_LABEL being a child of the project
within I make submission.
I have a library target named MY_LABEL, for which I set:
set_property(TARGET MY_LABEL PROPERTY LABELS MY_LABEL)
for each testcase $tc added with ADD_TEST I set:
set_property(TEST ${tc} PROPERTY LABELS MY_LABEL)
Thank you,
Wojtek
--
Japonia czy Niemcy?
Tutaj znajdziesz samochody z całego świata!
Sprawdź http://linkint.pl/f288b
___
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] Merging gcc unit tests into a TI DSP crosscompiler build system
Hi, in our company we have a robust cmake-based build system which utilizes TI DSP cgtools compiler. Aside from that we are developing gcc-based unit tests (CxxTest coupled with CMake/CTest/CDash combo). We are considering merging the latter into the former, but we kind of don't even know how to put them together so that two C/C++ compilers can coexist in a single CMake build system. I tried inserting ADD_SUBDIRECTORY pointing to one of the test suites CMakeLists.txt file into the main CMakeLists.txt of the core build system but it blows everything up. Has anyone attempted this kind of configuration already ? Is it achievable with CMake at all ? We are using CMake 2.6.4 release. Thanks in advance, Wojtek -- Duzi chlopcy lubia wampiry i krew. http://linkint.pl/f2718 ___ 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 misses out with code coverage on files whose path is outside PROJECT_SOURCE_DIR
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wojciech Migda pisze: Hi, I have found a strange behaviour of ctest when performing code coverage analysis for unit tests. When the unit test binary is linked with a static library compiled from source files located outside the PROJECT_SOURCE_DIR then although the *.gcov files are generated, they are missed out from the final xml file. LastCoverage_*.log from the Testing/Temporary folder contains the an error of a form: Errors: Something went wrong. Cannot find file: /home/scr/code_coverage/src_B/src_B.c in source dir: /home/scr/code_coverage/dir_A or binary dir: /home/scr/code_c overage/dir_A Coverage.xml will then contain data for src_A library, but not for src_B. If I make a symbolic link to src_B within dir_A (where top-level CMakeLists.txt is located) then the code coverage will be summarized for src_B as well. Should I submit a bug ? Tarball with an example is attached. With best regards, Wojtek Bug submitted: http://www.vtk.org/Bug/view.php?id=9678 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKzNZY0iFl+nAyImcRAvj5AJ4sH/E5OQi/8BTwFGva2VIjOgcDFACfUm1b hvvG4SFoUV+wckQDkAR5PEA= =xzFg -END PGP SIGNATURE- --- Zapytaj wr��k�! Kliknij http://link.interia.pl/f238d ___ 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 - C Unit Testing Framework
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dixon, Shane pisze:
!-- /* Style Definitions */ p.MsoNormal, li.MsoNormal,
div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt;
font-family:Times New Roman;} a:link, span.MsoHyperlink
{color:blue; text-decoration:underline;} a:visited,
span.MsoHyperlinkFollowed {color:purple; text-decoration:underline;}
span.EmailStyle17 {mso-style-type:personal-compose;
font-family:Arial; color:windowtext;} @page Section1 {size:8.5in
11.0in; margin:1.0in 1.25in 1.0in 1.25in;} div.Section1
{page:Section1;} --
I’m using CMake for all of my building. Currently I’m just working
on Windows XP, but I’d like to leave things open for Linux builds in
the near future. Any suggestions on the best testing framework for
a C project that will be cross-platform compatible and I can use it
with Windows and Linux? I’d like something that works well with
CTest. (i.e. a command-line interface is probably ideal).
I looked at cfix, but that seems Windows specific. The CUnit
project looks like it hasn’t been updated in a long time.
Any suggestions?
I'm satisfied with CxxTest, which I'm using for strict C code unit
testing. I'm able to compile and run testcases under solaris and
cygwin within CMake/CTest framework.
- -Wojciech
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFKy3XM0iFl+nAyImcRApIZAJ0SuG0PM7DtZMTjigGZoKg0oPlu7QCePrqI
3KVXxO6pMMva5ALB04O1hGk=
=M1IZ
-END PGP SIGNATURE-
--
Zobacz najwiekszy samolot na swiecie!
Kliknij http://link.interia.pl/f238f
___
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] CTest misses out with code coverage on files whose path is outside PROJECT_SOURCE_DIR
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I have found a strange behaviour of ctest when performing code coverage analysis for unit tests. When the unit test binary is linked with a static library compiled from source files located outside the PROJECT_SOURCE_DIR then although the *.gcov files are generated, they are missed out from the final xml file. LastCoverage_*.log from the Testing/Temporary folder contains the an error of a form: Errors: Something went wrong. Cannot find file: /home/scr/code_coverage/src_B/src_B.c in source dir: /home/scr/code_coverage/dir_A or binary dir: /home/scr/code_c overage/dir_A Coverage.xml will then contain data for src_A library, but not for src_B. If I make a symbolic link to src_B within dir_A (where top-level CMakeLists.txt is located) then the code coverage will be summarized for src_B as well. Should I submit a bug ? Tarball with an example is attached. With best regards, Wojtek -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKy5hA0iFl+nAyImcRAlkQAJwNLAuag/Teee8gxLvLaqfQarq5PACbBWJ4 zztljbPpvhQUYqwZ8KtbmqM= =7ecV -END PGP SIGNATURE- --- Zapytaj wr��k�! Kliknij http://link.interia.pl/f238d code_coverage.tar.gz Description: application/gzip ___ 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] Pass value from CMake to source file?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eric Noulard pisze:
2009/10/4 motes motes mort.mo...@gmail.com:
Is it possible to send a user specified path from CMake to the final
application (make it visible)? Depending on which machine I build my
application on the path to some images may vary. I was therefore
thinking to specify this path when building with CMake like:
FIND_PATH(IMAGE_DIR REQUIRED)
and then in my application do:
#includestring
int main(){
std::string img0 = IMAGE_DIR + image0.png;
return 0;
}
You should use CONFIGURE_FILE for that.
Look for example this section of the Wiki:
http://www.cmake.org/Wiki/CMake_HowToDoPlatformChecks
My personal favourite would be preprocessor macro:
FIND_PATH(IMAGE_DIR REQUIRED)
ADD_DEFINITIONS( -DIMAGE_DIR=${IMAGE_DIR} )
- -Wojciech
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFKyHJR0iFl+nAyImcRAhy/AKCE4AbpCTP7hfvylG2cr+nJAScpJQCcDZHl
iJ/ur6pjOCllzZKFxzHfbqs=
=TA6d
-END PGP SIGNATURE-
---
Zapytaj wró¿kê!
Kliknij http://link.interia.pl/f238d
___
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] Disabling ranlib on *nix systems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I'd like to force CMake not to execute ranlib on *nix system. I've got a workaround - I set CMAKE_RANLIB to 'echo' - but it's nonelegant. Is there another way to disable execution of ranlib ? There is a reason why I need that: TI DSP linker for Linux doesn't handle ranlib'ed libraries. Thanks, - -Wojciech -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKwPya0iFl+nAyImcRApcmAJ4osyJYCqkCfn3VoJ6SA7RMIcdneACffw95 91Hx0dCjoFLkF0iytMqnHcc= =JjJ5 -END PGP SIGNATURE- -- Bezplatne konto i limit do 100 tys. Otwierasz? http://link.interia.pl/f2342 ___ 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] Dependencies resolution for generated assembler files (TI DSP, s62/h62)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, projects created using Texas Instruments DSP tools involve compilation of assembler source (*.s62) and header (*.h62) files generated using a dedicated tool (tconf). Those source files include headers using a directive of a form: .include file_name Since I could not make CMake scan dependencies for these assembler files automatically, I've got two questions: 1. CMake manual with regard to assembler support is not clear whether dependency scanning will work or not. Is this particular (.include directive) case supported by CMake ? 2. I tried specifying dependencies for the assembler source files manually (set_source_files_properties/object_depends) but it didn't seem to work. Is this possible at all for generated assembler source files ? Thanks for help, - -Wojtek -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKv8/S0iFl+nAyImcRAg39AKCj99PqTTFds8omxPtWSSI2v1YdRACfczGU qY8qjB4XgwYacMyoCrF966Y= =TgWj -END PGP SIGNATURE- -- Wyszukiwarka tanich lotow! Sprawdz http://link.interia.pl/f233e ___ 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.0 RC 1 ready for testing!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 and what about clearcase snapshot views updating ? Any plans ? Wojciech Michael Wild pisze: Usually I use cvs update -dARP which IMHO should probably be the default, because that's what people (i.e. me) expect from an update. Are there any plans for CMake (and other Kitware projects) to switch over to a more contemporary VCS, such as git, hg or bzr (in the order of my preference :-))? Michael On 26.09.2009, at 14:49, Eric Noulard eric.noul...@gmail.com wrote: 2009/9/26 Alexander Neundorf a.neundorf-w...@gmx.net: On Saturday 26 September 2009, Andreas Pakulat wrote: Not sure which one is newer, but I just cvs up'ed to the CMAKE-2-8 branch and tried to build and it failed with this: [ 90%] Building CXX object Source/CMakeFiles/CTestLib.dir/CTest/cmCTestUpdateCommand.o In file included from /home/andreas/src/CMake/Utilities/ cm_xmlrpc.h:26, from /home/andreas/src/CMake/Source/CTest/cmCTestSubmitHandler.cxx:28: /home/andreas/src/CMake/Utilities/cmxmlrpc/xmlrpc.h:32:36: error: I think something went wrong with your checkout/update. The directory CMake/Utilities/cmxmlrpc/ should be empty/non-existant. You may need to add pruning -P option to your cvs udpate command. I did a fresh checkout and had no trouble compiling CMake. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake ___ 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 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKvi/r0iFl+nAyImcRAj0UAKC+VfSxTZldj2qQR+GV2vItQ0sLPQCgugH3 E9Qc9pF8Nja5bd/qimjYzgg= =p4Y0 -END PGP SIGNATURE- -- Bezplatne konto i limit do 100 tys. Otwierasz? http://link.interia.pl/f2342 ___ 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] Extending list of files subject to coverage with CTest
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I am considering adding code coverage metrics to the executed unit tests. I get it work - I mean gcov i run and data is collected. However, from what I observed files subjected to coverage analysis is limited to those explicitly listed in the command used to create the executable. The code I'm most interested in obtaining coverage results is linked from a static library, which is missed out. I know that there is a variable which allows to limit coverage to specific files, but what if I want to extend it to files compiled into static library objects ? Thanks for help, - -Wojciech -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKuSYa0iFl+nAyImcRAly3AJ9u9W/DxaOId78f0cgBBvicTfxGGwCfbtAI s+ZpWbO0DioOyuowXTMrAww= =IMwP -END PGP SIGNATURE- -- Zobacz nowego Lambo reventon roadster Klikinij http://link.interia.pl/f2363 ___ 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 and CxxTest
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Blezek pisze: We tackled this using a hack-ish CMake command for Google Tests that found all our tests in the source code, and generated CTest commands for them. You could do a similar thing on a test suite. Details are here: http://www.itk.org/Wiki/Proposals:Increasing_ITK_Code_Coverage#Google_Test -dan Thank you very much - this is pretty much the idea I started converging to. What you've done with ITK will work 100%. I just need to tweak the CxxTest generator script. BR, - -Wojciech -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKt8Rm0iFl+nAyImcRAl3yAJ9oSp7Cj5CvVfjvq9wiUQjGmnqQGgCePT/o VdtdcPqeZgOzqBw2r+Aox5E= =v868 -END PGP SIGNATURE- -- Zobacz jak mieszka Kasia Zielinska! Kliknij http://link.interia.pl/f2343 ___ 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] Ctest and CxxTest
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I was wondering about an improvement for the way CxxTest unit tests are coupled with CTest. Right now when CTest submits results to CDash the tests are counted by binaries executed. In my unit tests each binary corresponds to an entire suite (approx. 150 testcases grouped within single CxxTest class). I'd see it very useful to have CTest operate with CxxTest based unit tests on a testcase level. Has anyone stumbled upon similar problem and got ideas / solutions ? Thanks for assistance, - -Wojciech -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKtjXN0iFl+nAyImcRAo/BAKCCjLfj8i+DjwxV3XDKO7drCSHPKQCfVl4a MdCJI1BEpFFviP6wjN8o5JM= =KGBE -END PGP SIGNATURE- -- Kawalerka za 79 000 zl! Sprawdz http://link.interia.pl/f2348 ___ 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 and CxxTest
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philip Lowman pisze: You could split up your testcases into multiple CxxTest classes. You could check to see if the cxxtest code generator supports preprocessor statements in generating test runners. Then you could group your tests by #ifdef / #endif...? Alternatively if it's not supported you may be able to modify the code generator to output multiple runners depending on the tests you want to run, e.g. cxxtestgen.pl --enable-test foo I think splitting things up probably would be the easiest approach. On Sun, Sep 20, 2009 at 10:01 AM, Wojciech Migda wojtek.g...@interia.pl wrote: Hi all, I was wondering about an improvement for the way CxxTest unit tests are coupled with CTest. Right now when CTest submits results to CDash the tests are counted by binaries executed. In my unit tests each binary corresponds to an entire suite (approx. 150 testcases grouped within single CxxTest class). I'd see it very useful to have CTest operate with CxxTest based unit tests on a testcase level. Has anyone stumbled upon similar problem and got ideas / solutions ? Thanks for assistance, -Wojciech Indeed, splitting is the easiest approach, albeit it adds additional effort - when a new test is added to a suite CMakeLists.txt has to be updated accordingly. If my idea how CTest works when it uploads results to CDash is correct then it only looks at the return code of the executed binary and captures its output. What if there was an option for CTest to work in a multiple-testcases mode where the output returned by the executed binary would be formatted in a way so as CTest would be able to parse it and process into CDash xml files with information on all tests executed. Just a thought, I have no idea how complicated that would turn out to be. I also thought about the binary itself being able to run single testcases on the basis of command line arguments, but that would require parallel information being stored in CMakeLists.txt, which again add effort. I'll see if I have more ideas. Thanks, - -Wojtek -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKtkz70iFl+nAyImcRAsPSAJ4yMjKSb96NZ02awttzwwu/nHZRhgCfQ2KZ VEM63SdgrUUA4OIXGApKJd8= =4utB -END PGP SIGNATURE- -- Bezplatne konto i limit do 100 tys. Otwierasz? http://link.interia.pl/f2342 ___ 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] OUTPUT_REQUIRED_FILES - how does it work ?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi again,
while exploring possibilities to solve dependency problems I took a
peek at the OUTPUT_REQUIRED_FILES command.
I constructed simple CMakeLists.txt
OUTPUT_REQUIRED_FILES( bar.c baz.txt )
ADD_LIBRARY( foo bar.c )
and the contents of bar.c is:
#include stdio.h
int main()
{
puts(hello world!);
return 0;
}
after running cmake baz.txt is created, but its empty. Building the
library with make gives no effect neither. I tried to run
OUTPUT_REQUIRED_FILES on bar.o (depend.make contains dependencies on
bar.o) but it didn't help.
Can anyone point me in the right direction ?
Thanks in advance,
- -Wojciech
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFKqUE+0iFl+nAyImcRAt4kAJ4lqlSb1Nm+TQJrkwCuT8n/9szy0ACfUslV
H7NgAJIUnSNPr5YDgsj3Vy0=
=thTx
-END PGP SIGNATURE-
--
Wygraj telefon HTC Touch Diamond 2.
Sprawd� http://link.interia.pl/f233f
___
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] Generated source files and dependencies(+) (Wojciech Migda)
Użytkownik Clinton Stimpson napisał(a):
From: Clinton Stimpson
Subject: Re: [CMake] Generated source files and dependencies(+)
(Wojciech Migda)
To: cmake@cmake.org
On Tuesday 08 September 2009 02:14:45 pm Wojciech Migda wrote:
Why not include it in the foo target, instead of making a new
a_h_gen target and doing extra dependencies manually?
Firstly, we have hundred of source files which may indirectly depend
generated source files, so we want such information to be covered by
cmake dependency scanner itself - the problem is that there is no
link
between the library target and the header target.
That's why I suggested
ADD_LIBRARY(foo STATIC a.c ${CMAKE_CURRENT_BINARY_DIR}/a.h)
It creates the generated headers for foo, then does the dependency
scanning
for foo, then compiles files.
Here's what I got:
$ make
[ 50%] Generating a.h
Scanning dependencies of target foo
[100%] Building C object CMakeFiles/foo.dir/a.o
Linking C static library libfoo.a
If that doesn't work for your case, can you be more specific on why it
doesn't?
hi, your proposal suggests implicit addition of dependency on a.h for the
library. We have tens of libraries, some of which might need dependency on
a.h, some might not. If we add this dependency on those which do not need
it then they will be rebuilt unnecesarilly if the a.txt changes.
What I'd like to see is cmake take care of the dependencies in a way that
when I type 'make foo' and a.txt is changed, then a.h would be
regenerated/created and foo rebuilt with new a.h. I guess cmake has got all
necessary information to convey such operation, since it does scanning of
dependencies on a.c to know its dependency on a.h, it knows that there is a
rule for a.h generation, so why not combine the two automaticaly and make
it work together ?
-Wojciech
--
Lecza czy truja? Poczytaj o niezwyklych wlasciwosciach grzybow.
Sprawdz http://link.interia.pl/f232b
___
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] Generated source files and dependencies(+) (Wojciech Migda)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alexander Neundorf pisze:
On Tuesday 08 September 2009, Wojciech Migda wrote:
Why not include it in the foo target, instead of making a new
a_h_gen target and doing extra dependencies manually?
Firstly, we have hundred of source files which may indirectly depend
generated source files, so we want such information to be covered by
cmake dependency scanner itself - the problem is that there is no link
between the library target and the header target.
By no means we want to specify such dependencies manually - that would
be a nightmare.
If you mean by specifying manually adding the generated header files
manually
to the targets, this can be made much easier with the support of some
macro:
macro(generate_stuff srcs )
...
add_custom_command(OUTPUT foo.h ...)
...
set( ${srcs} ${${srcs}} foo.h)
endmacro()
set(mySrcs main.cpp bar.cpp)
generate_stuff(mySrcs template1.xml template2.xml)
add_executable(hello ${mySrcs} )
We are using that a lot e.g. in KDE4.
But this implies that we know beforehand that certain library has
dependency on the generated header or not and that we will construct
the CMakeLists.txt with that in mind. This makes the whole thing not
much different than doing dependency scan of headers outside cmake and
embedding the results by hand. If during the course of development the
dependency of a certain target on a.h will change the contents of the
CMakeLists.txt would have to be changed as well - I don't take this as
an elegant solution, to mention maintenance efforts only.
Isn't there any way to enable cmake to scan this dependency
automatically ?
I even considered using OUTPUT_REQUIRED_FILES to obtain information
whether certain files would have dependency on the generated header to
conditionally enable dependency on it. But this would be yet another
workaround to achieve something I'd expect from this kind of tool as
cmake is to be done transparently. Frankly, I'm a bit surprised that
cmake hasn't got such feature yet. Or I'm just wrong ?
Thanks in advance,
- -Wojciech
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFKp+n60iFl+nAyImcRAtGbAJsFNnvRbljipG9VGL88jyrhAoLFpwCePV18
436+WsTsX8daghTVTGtQhjc=
=WLqz
-END PGP SIGNATURE-
--
Praca za granic±? Zobacz oferty!
http://link.interia.pl/f2331
___
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] Generated source files and dependencies(+) (Wojciech Migda)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
some time ago there was a discussion, which has highlighted problem I
am facing now, but it did not provide final conclusions
(http://www.cmake.org/pipermail/cmake/2008-September/024093.html).
Take this example:
- --
INCLUDE_DIRECTORIES( ${CMAKE_CURRENT_SOURCE_DIR} )
SET_SOURCE_FILE_PROPERTIES( ${CMAKE_CURRENT_SOURCE_DIR}/a.h PROPERTIES
GENERATED TRUE )
ADD_CUSTOM_COMMAND(
OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/a.h
COMMAND echo \\#define STAMP `date` \ a.h
DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/a.txt
)
ADD_CUSTOM_TARGET( a_h_gen DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/a.h )
ADD_LIBRARY( foo STATIC a.c )
- -
Here we have file a.c which includes file a.h.
a.h is generated, with dependency on a.txt.
What I'd expect from the above (and what ZNV hinted in the 2008
thread) building foo library should check dependencies of a.c and if
a.h doesn't exist generate it or it a.txt has changed regenerate a.h
However, files generated with cmake 2.6.4 show that:
1. in Makefile2 a.c has no dependencies on a.h or a_h_gen
2. depend.make for foo library has dependency on a.h only if a.h
existed at the time of cmake execution or during dependency scanning
for a.c
The result is that building foo doesn't generate a.h nor a.h is
refreshed if a.txt changed even though depend.make for foo lists a.h
as its dependency. If I add the following line at the end:
ADD_DEPENDENCIES( foo a_h_gen )
a dependency for foo on a_h_gen will appear in Makefile2 and
everything will work as expected.
This however, in a real life example I am working on there are
hundreds of source files and tens of libraries which indirectly may
depend on a generated header and thus manual specification of
dependency between built library and generated file is simply impractical.
Thus, my question is whether I am missing something in my example
CMakeLists.txt or cmake at this stage is simply unable to handle such
situation.
In the 2008 discussion ZNV illustrated exactly the same situation by
the single vs. two-level dependency illustration, and Esben's response
was that properly constructed CMakeLists.txt file shall enforce single
level of dependencies. Nonetheless, the example above shows that it is
not the case.
Any hints allowing me to reach the desired cmake behaviour will be
appreciated. THANKS.
- -Wojciech
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFKprET0iFl+nAyImcRAritAJ94VawRLcOh55U6uBu+QECWbVKB7wCffST5
TYAJVZC8mGhNp3yO9fVue2Y=
=LYc3
-END PGP SIGNATURE-
--
Wykonaj diagnostyke skory i odbierz swoj Prezent!
http://link.interia.pl/f22f1
___
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] Generated source files and dependencies(+) (Wojciech Migda)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Why not include it in the foo target, instead of making a new a_h_gen target and doing extra dependencies manually? Firstly, we have hundred of source files which may indirectly depend generated source files, so we want such information to be covered by cmake dependency scanner itself - the problem is that there is no link between the library target and the header target. By no means we want to specify such dependencies manually - that would be a nightmare. If we skip the a_h_gen target the header generation target will not appear in Makefile2, which I think is one of the required links for everything to work. The last remaining link is missing (which we may mimic by hand with the add_dependencies command) by I don't know how to fix it so it becomes automatic within the build system and dependency scanner. - -Wojciech -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKprs10iFl+nAyImcRAo5XAJ4scpKe/E9g5uTZcFPyLYroJmD0oACghdom T6TR/kPv+kLYga/wCXObbwA= =q652 -END PGP SIGNATURE- -- Marcin Gortat #8211; gwiazda NBA w naszej reprezentacji! Czytaj wiecej http://link.interia.pl/f232a ___ 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] Cygwin performance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, cygwin of known for its poor performance wrt some disc i/o operations. I'm already making some changes which will enhance cmake timings on cygwin, would you guys be interested receiving them, or maybe somebody from cmake team is already working on that ? BR, Wojtek -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJwVfZ0iFl+nAyImcRAt65AJ0WVLzw48TrIDmN4caMS/LC6hM5OwCfTBH9 t+i4rSXzDH2Ko4/c8Yt4MTM= =yM4J -END PGP SIGNATURE- -- Program tylko dla graczy komputerowych! Ogladaj http://link.interia.pl/f207f ___ 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] Common binary dir and failed local headers dependencies
Bill Hoffman pisze:
Wojciech Migda wrote:
Hi again,
this workaround seems to do a trick:
in cmDependsC::WriteDependencies I've added a local variable to store
path to the source file being scanned for dependencies:
std::string root_dir =
cmSystemTools::GetFilenamePath(this-LocalGenerator-Convert(src,
cmLocalGenerator::HOME_OUTPUT,
cmLocalGenerator::MAKEFILE));
later in the function I've replaced
if((*i) == .)
{
tempPathStr += current.FileName;
with
if((*i) == .)
{
tempPathStr += root_dir + / + current.FileName;
Could anyone from the cmake dev team evaluate this proposal ?
There are other things that will break because of this. Things like
percent done. The build directories were designed with the thought that
they should be unique.
Try LIBRARY_OUTPUT_PATH to place the libraries, that is how it should be
done.
-Bill
thanks for a tip Bill,
seems to work, although I yet to have to check all the places where the
paths might become broken, but that is just a minor issue (we directly
refer in at least few points to specific object files, whose path will
now change - see below).
I've changed the ADD_SUBDIRECTORY invocations to refer to separate
binary folders within common binary one as
${common_bin_dir}/${target_name} (Mike Jackson has proposed this in
his response as well). Anyway, the dependencies are now handled properly
(as expected).
Thanks again,
Wojtek
--
Zyskaj tak jak ja 9% na lokacie w pierwszym miesiacu!
Sprawdz! http://link.interia.pl/f207b
___
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] Common binary dir and failed local headers dependencies
Hi all, I have a build system with several subtargets residing in respective subfolders. What is important - I'm using common binary directory for all targets. The command I use is: ADD_SUBDIRECTORY( nth_subfolder common_binary_dir ) The common binary folder was chosen to have all static libraries created by respective subtargets stored in a single place. However, this leads to a problem with dependencies derived from C/C++ source files to headers which are located in local subdirectories and not in common headers storages. The build system has got few common include folders which are defined in the topmost CMakeLists.txt file, and for each subtarget its own CMakeLists.txt adds local directory to the include list. This works for compilation, as all -I compiler switches are generated exactly as they should. Unfortunately, when cmake determines target dependencies (depend.make file) it looks for headers based on information stored in the CMakeFiles/CMakeDirectoryInformation.cmake file stored in the binary directory, which in my case is common for all targets. This means that with each target the contents of CMakeDirectoryInformation.cmake is overwritten with the information derived from the last processed target. As a result during build time when dependencies are being checked headers which are present only in local directories are not taken into account and a large part of dependency information is being lost. Thus, I'd like to ask for advice: should I change the organization of my build system to get rid of the common binary directory, or should I file a feature request for cmake to update and not overwrite contents of the CMakeDirectoryInformation.cmake file. With kind regards, Wojtek Migda -- Teraz gry - program dla prawdziwych graczy! http://link.interia.pl/f2080 ___ 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] Common binary dir and failed local headers dependencies
some follow-up to my previous post: I don't see an easy way to fix the presented problem within cmake scripting mechanisms other than adding own script called at the setup time for dependencies check and adding those dependencies to objects using SET_PROPERTIES* directives. However, as far as I could look into cmake code myself, the change I'd see being made was an interpretation of the . directory added using the INCLUDE_DIRECTORIES directive. CMake inserts . to the list of include dirs stored in CMakeDirectoryInformation.cmake but then when it comes to dependency resolution in the cmDependsC::WriteDependencies method the . directory is interpreted literally, that is the path to the header being checked for existence is simply its filename, assuming the current directory for its location. Thus, if the dependencies are checked using the cmake -E cmake_depends (as in any build.make file) the current directory is the topmost project folder. Instead . shall be translated to the current target source folder, taken as one of the arguments of cmake -E cmake_depends arguments: start-src-dir. Any thoughts on that ? Wojtek Migda -- 8 marca - wyslij kwiaty bliskim Ci kobietom! http://link.interia.pl/f208f ___ 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] Common binary dir and failed local headers dependencies
Hi again,
this workaround seems to do a trick:
in cmDependsC::WriteDependencies I've added a local variable to store
path to the source file being scanned for dependencies:
std::string root_dir =
cmSystemTools::GetFilenamePath(this-LocalGenerator-Convert(src,
cmLocalGenerator::HOME_OUTPUT,
cmLocalGenerator::MAKEFILE));
later in the function I've replaced
if((*i) == .)
{
tempPathStr += current.FileName;
with
if((*i) == .)
{
tempPathStr += root_dir + / + current.FileName;
Could anyone from the cmake dev team evaluate this proposal ?
BR,
Wojtek
Wojciech Migda pisze:
some follow-up to my previous post:
I don't see an easy way to fix the presented problem within cmake
scripting mechanisms other than adding own script called at the setup
time for dependencies check and adding those dependencies to objects
using SET_PROPERTIES* directives.
However, as far as I could look into cmake code myself, the change I'd
see being made was an interpretation of the . directory added using
the INCLUDE_DIRECTORIES directive. CMake inserts . to the list of
include dirs stored in CMakeDirectoryInformation.cmake but then when it
comes to dependency resolution in the cmDependsC::WriteDependencies
method the . directory is interpreted literally, that is the path to
the header being checked for existence is simply its filename, assuming
the current directory for its location. Thus, if the dependencies are
checked using the cmake -E cmake_depends (as in any build.make file)
the current directory is the topmost project folder. Instead . shall
be translated to the current target source folder, taken as one of the
arguments of cmake -E cmake_depends arguments: start-src-dir.
Any thoughts on that ?
Wojtek Migda
--
8 marca - wyslij kwiaty bliskim Ci kobietom! http://link.interia.pl/f208f
___
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
--
Program tylko dla graczy komputerowych!
Ogladaj http://link.interia.pl/f207f
___
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] Unwanted quoting of $
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, | | I’ve run into a problem trying to pass command line parameters to Visual C++, that contain the $ character. I’m building a C++/CLI module, and need to reference some .NET assemblies, with the /FU compiler option. Since Visual Studio stores the installation location of .NET in one of its own macros, $(FrameworkDir), I want to pass the following compiler options verbatim to Visual Studio: | | | | /FU $(FrameworkDir)/v2.0.50727/System.dll | | | | But if I go | | | | ADD_DEFINES( /FU $(FrameworkDir)/v2.0.50727/System.dll ), | | | | , what I end up with in Visual Studio is | | | | /FU “$”(FrameworkDir)/v2.0.50727/System.dll | | | | , which obviously is not going to work. | | | | So what do I need to do to pass a $ character through to Visual Studio, without the quotes? I’m using cmake 2.6.0 . | Just $$. I had the same problem and googled it here: http://marc.info/?l=cmakem=120043575105964w=2 - -Wojciech -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIZTUg0iFl+nAyImcRAu5qAKCA4lnDcvBxVqTHgU//9WXlSsMMCwCeJq7A OhCUjRKOfGQDb03wDatYm2w= =dbkh -END PGP SIGNATURE- -- Z Map24 Twoja droga jest prosta! Sprawdz! kliknij http://link.interia.pl/f1e3b ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ASM Cross Compiler Help
Hi, I see that there are some CMake modules that seem to be referring to ASM Compilers (I am assuming this is an assembly compiler) and the release notes for 2.6 seem to confirm this. I can't seem to find any information on how to configure it. I am setting up a cross-compiler environment and I have the C and C++ compilers working and I can add custom commands to build the assembly files but it would be a lot nicer if they got handled along with the C sources. Does anyone know how I might go about doing this or maybe provide some pointers? The entire assembly compiler system seems to be slightly lacking in documentation. Did you try looking here: http://www.cmake.org/Wiki/CMake_Cross_Compiling For me it was enough. You might also want to try google some code: http://www.google.pl/codesearch?hl=pllr=q=file%3ACMakeLists.txt+ASMsbtn=Szukaj -Wojciech -- Sprawdz, czy jestes lepszy, niz Leo! kliknij http://link.interia.pl/f1e2f ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] File-dependent rebuild
I'd like to have cmake rebuild upon detecting changes made to a file being part of the project (simple timestamp difference might suffice). This file is not a compiler input itself, but is used to determine the list of source files upon which the library to build is dependant. The file of interest is a versioned object. OK, I've found a solution, mainly inspired by this thread (http://www.cmake.org/pipermail/cmake/2007-July/015357.html). To explicitly add cmake dependency, which basicaly means calling AddCMakeDependFile, I've used the CONFIGURE_FILE command. In this context it simply copies the file to a designated directory (or files, a total of which in the whole build tree in my case is approx. 140) and ends up adding required entry to the CMAKE_FILE_DEPENDS variable in CMakeFiles/Makefile.cmake. -Wojciech -- Podbij Dziki Zachod!Gra strategiczna online Sprawdz http://link.interia.pl/f1dff ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Dependencies handling vs. timestamp
Hi, does cmake support handling of a situation when the timestamp of the file upon which trigger for a given action is dependent (compilation, build system regeneration) moves to past? -Wojciech -- Sprawdz, czy jestes lepszy, niz Leo! kliknij http://link.interia.pl/f1e2f ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMAKE 2.6.0: Wrong dependencies when CMakeLANGInformation.cmake is missing
/ It's an embedded system with it's own proprietary OS. / own proprietary OS == you/your company wrote it or an RTOS one can buy ? Adding support for some commercial RTOS like e.g. VxWorks to cmake would be ok. Yes, it is our own RTOS, not publicly available. / Why do you need CMAKE_FORCE_[C|CXX]_COMPILER() ? // // I'm cross-compiling on Cygwin/U*IX (c, c++, asm) / No, I mean, why do you need to FORCE it ? In most cases the compilers should be able to build a simple executable for the target, also when cross compiling. What fails ? It does not build standalone executables, because it was never supposed to, so I've followed the eCos example from http://www.cmake.org/Wiki/CMake_Cross_Compiling BR, -Wojciech -- Podbij Dziki Zachod!Gra strategiczna online Sprawdz http://link.interia.pl/f1dff ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] File-dependent rebuild
Hi, I'd like to have cmake rebuild upon detecting changes made to a file being part of the project (simple timestamp difference might suffice). This file is not a compiler input itself, but is used to determine the list of source files upon which the library to build is dependant. The file of interest is a versioned object. Thanks in advance, Wojciech -- Podbij Dziki Zachod!Gra strategiczna online Sprawdz http://link.interia.pl/f1dff ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMAKE 2.6.0: Wrong dependencies when CMakeLANGInformation.cmake is missing
I've prepared a patch against the 2.6.0 version. Unfortunately I could
not find the patch format instructions for cmake, so I took those for
linux kernel (diff -up).
Thanks for the patch.
The asm support is still very new, so thanks for pointing out issues.
Can you create a small test project so I can reproduce the problem here ?
Thanks
Alex
Sure, the tarball is attached. Please compare behaviour when line #72 is
{un}commented in CMakeLists.txt
BR,
Wojciech
--
Tanie rozmowy!
Sprawdz http://link.interia.pl/f1e22
depissue.tar.gz
Description: GNU Zip compressed data
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMAKE 2.6.0: Wrong dependencies when CMakeLANGInformation.cmake is missing
Alexander Neundorf pisze: On Sunday 08 June 2008, Wojciech Migda wrote: As it appeared the . entry was present due to me using user-defined assembler compiler for the build. Commenting out the relevant ENABLE_LANGUAGE command in CMakeLists.txt led to proper behaviour. But why ? I looked at the cmGlobalGenerator::EnableLanguage function and after debugging I noticed that when a check for CMakeLANGInformation.cmake was made, a file which was missing - I did put all assembly compiler definitions into CMakeLANGCompiler.cmake, a call to GetModulesFile returned an empty string. ReadListFile executed with that empty string did not fail, and that probably led to the . directory being present in the CMAKE_MAKEFILE_DEPENDS list. Another way to fix this would be to fail if CMakeLANGInformation.cmake is not found, so you would have noticed that something is going wrong. Maybe this would be a better approach, then the support for languages will be more consistent. Well, that's what I tried to introduce with the patch,although the termination doesn't happen immediately after an error is found, but the generation continues to the end. Bill ? I confirmed that by setting the CMAKE_LANG_INFORMATION_LOADED variable before execution of ENABLE_LANGUAGE - the dependencies were correct. Nonetheless I'd expect that a fix with additional check for ifpath being empty is introduced in cmGlobalGenerator.cxx/cmGlobalGenerator::EnableLanguage. I've prepared a patch against the 2.6.0 version. Unfortunately I could not find the patch format instructions for cmake, so I took those for linux kernel (diff -up). Looks ok. I had a look at your files. What system are you building for ? Is it some rolled-your-own OS or some OS generally available ? If so, we could add support for it to cmake directly. It's an embedded system with it's own proprietary OS. Why do you need CMAKE_FORCE_[C|CXX]_COMPILER() ? I'm cross-compiling on Cygwin/U*IX (c, c++, asm) Why do you need to set CMAKE_[C|CXX]_OUTPUT_EXTENSION_REPLACE to true ? Otherwise the object file names would have a form source_filename.o, e.g. foo.c.o, or irq.S.o . It didn't suit me for some legacy backward compatibility reasons (e.g. linker scripts with hardcoded paths). This looks like there is something not working which should work. Since eventually I got it working I took some things for granted, although they seemed more like black magic to me. I blamed the cross-compiling framework but if you say it might be some cmake deficiencies itself, then I'll look through the files to see if I could report some more suspicious behaviour. Thanks, Wojciech Bye Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake --- Sprawdz jak zdobyc zdrowy usmiech! Kliknij http://link.interia.pl/f1e26 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] CMAKE 2.6.0: Wrong dependencies when CMakeLANGInformation.cmake is missing
Hi,
I did have a problem with cmake regenerating the whole build tree
everytime I executed make. As it turned out the rebuild was done due to
the dependency check made in
cmGlobalUnixMakefileGenerator3::WriteMainCMakefile. It came out that the
CMAKE_MAKEFILE_DEPENDS list in Makefile.cmake contained the current
directory (.) entry, which appeared to be always more recent than the
newest output - CMakeFiles/cmake.check_cache. It was enough to remove
the . entry to get rid of the rebuild. Anyway I kept investigating.
As it appeared the . entry was present due to me using user-defined
assembler compiler for the build. Commenting out the relevant
ENABLE_LANGUAGE command in CMakeLists.txt led to proper behaviour. But
why ? I looked at the cmGlobalGenerator::EnableLanguage function and
after debugging I noticed that when a check for
CMakeLANGInformation.cmake was made, a file which was missing - I did
put all assembly compiler definitions into CMakeLANGCompiler.cmake, a
call to GetModulesFile returned an empty string. ReadListFile executed
with that empty string did not fail, and that probably led to the .
directory being present in the CMAKE_MAKEFILE_DEPENDS list.
I confirmed that by setting the CMAKE_LANG_INFORMATION_LOADED variable
before execution of ENABLE_LANGUAGE - the dependencies were correct.
Nonetheless I'd expect that a fix with additional check for ifpath being
empty is introduced in
cmGlobalGenerator.cxx/cmGlobalGenerator::EnableLanguage.
I've prepared a patch against the 2.6.0 version. Unfortunately I could
not find the patch format instructions for cmake, so I took those for
linux kernel (diff -up).
--- cmake-2.6.0/Source/cmGlobalGenerator.cxx.orig2008-05-05
18:25:54.0 +
+++ cmake-2.6.0/Source/cmGlobalGenerator.cxx2008-06-08
15:28:43.986483015 +
@@ -415,10 +415,10 @@ cmGlobalGenerator::EnableLanguage(std::v
fpath += lang;
fpath += Information.cmake;
fpath = mf-GetModulesFile(fpath.c_str());
- if(!mf-ReadListFile(0,fpath.c_str()))
+ if(!mf-ReadListFile(0,fpath.c_str()) || fpath.empty())
{
cmSystemTools::Error(Could not find cmake module file:,
- fpath.c_str());
+CMake, lang, Information.cmake);
}
}
if (needSetLanguageEnabledMaps[lang])
The latest HEAD version 1.233 appears to have the same problem.
With best regards,
Wojciech Migda
---
Sprawdz jak zdobyc zdrowy usmiech!
Kliknij http://link.interia.pl/f1e26
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
