Re: [cmake-developers] Better Eclipse CDT support
Am 09.05.2011 23:32, schrieb Manuel Klimek: On Mon, May 9, 2011 at 2:30 PM, Manuel Klimek kli...@google.com wrote: On Sun, May 8, 2011 at 7:38 PM, Oliver Buchtala oliver.bucht...@jku.at wrote: Hi Alex, Manuel, and other interested watchers, I'd like to introduce a preview version of an Eclipse plugin 'CMakeWorkbench' which is combined with the CMake CDT7 generator developed lately. I try to reduce user actions for importing projects and managing working sets. By watching solution files generated with CDT7 generator automatic updating is achieved... Of course there are still some hitches... and obviously much space for improvement... but hey ;) that's is my first eclipse plugin Please find notes about installation: https://github.com/oliver/cmake-workbench/blob/master/doc/Install.markdown and a step by step HelloWorld on: https://github.com/oliver/cmake-workbench/blob/master/doc/examples/HelloWorld.markdown Please: I'd like to have your opinion and maybe some trying :) First impression: very nice. Somehow even the .h stuff works now :) No, it doesn't ... It now opens the projects in the background (which is nice) and had me thinking that there were no duplicated .cpp files in there any more for a moment. Yepp. This is still an issue. I filed issues on CDT and reopened the corresponding issue on my github. I hope I find a clean solution soon. Basically, I don't like my approach to have a link to the full tree. Causes trouble and brings redundancy. Hopefully, they (CDT gang) try to work on the Ctrl-Shift-R for includes. I will try to add more linked resources (e.g., flex input sources etc.) Linked folders raise so many problems right now :( Don't hesitate to add ideas, feelings, suggestions by means of issues or comments on my github :) Cheers, Oliver ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Better Eclipse CDT support
Am 06.05.2011 23:26, schrieb Alexander Neundorf: On Saturday 30 April 2011, Oliver Buchtala wrote: Am 30.04.2011 19:56, schrieb Oliver Buchtala: Am 30.04.2011 19:29, schrieb Alexander Neundorf: Nowadays, there are ways to deal better with that: linked folders, virtual folders and linked resources I'm not using Eclipse actively myself, I'm just maintaining the generator. But what people told me is that if the sources are not in a subdir of the project file, then the svn support of Eclipse does not work. Also if the sources are in a linked folder. Did this change ? Ok. Don't know. I have to check... Actually, there happened a lot around folders. Maybe this also works in the meantime. Nope. This is still not supported. My personal opinion is that I do not care about eclipse svn support. Other IDEs don't support this either (or not well). Also, in earlier days I have had not too good experiences with Subversive and Subclipse and always returned to doing svn from command line or other tools (e.g. TortoiseSVN). I looked a bit around in the internet and still find mainly bad remarks for those both plugins and suggestions not to do it from within Eclipse. When I look around my colleagues I find basically only positive remarks about the svn support in Eclipse ;-) This is also my impression from feedback from other users about the Eclipse generators, that the missing svn support in linked folders sucks. Alex Alright. Though, IMO SVN issues should not dominate CDT generation issues. But, you are totally right - this file system limitations in eclipse sucks... I consulted an eclipse guy these days... they are working on that and this is going to be better in e4 (=next generation)... For us, we have to be patient ;) Oliver ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Better Eclipse CDT support
Am 07.05.2011 00:02, schrieb Alexander Neundorf: On Friday 06 May 2011, Oliver Buchtala wrote: Am 06.05.2011 23:26, schrieb Alexander Neundorf: ... When I look around my colleagues I find basically only positive remarks about the svn support in Eclipse ;-) This is also my impression from feedback from other users about the Eclipse generators, that the missing svn support in linked folders sucks. Alex Alright. Though, IMO SVN issues should not dominate CDT generation issues. But, you are totally right - this file system limitations in eclipse sucks... I consulted an eclipse guy these days... they are working on that and this is going to be better in e4 (=next generation)... Ah. These two blog entries don't make it sound like a CDT for e4 will happen very soon ? http://cdtdoug.blogspot.com/2010/04/cdt-on-e4.html http://cdtdoug.blogspot.com/2010/06/im-not-anti-e4-im-just-busy-with- other.html Alex Hmmm. We have to be patient? ;) Nevertheless, the SVN problem might still be there, as it is also an issue with the SVN plugin impl... ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Better Eclipse CDT support
Am 30.04.2011 19:56, schrieb Oliver Buchtala: Am 30.04.2011 19:29, schrieb Alexander Neundorf: Nowadays, there are ways to deal better with that: linked folders, virtual folders and linked resources I'm not using Eclipse actively myself, I'm just maintaining the generator. But what people told me is that if the sources are not in a subdir of the project file, then the svn support of Eclipse does not work. Also if the sources are in a linked folder. Did this change ? Ok. Don't know. I have to check... Actually, there happened a lot around folders. Maybe this also works in the meantime. Nope. This is still not supported. My personal opinion is that I do not care about eclipse svn support. Other IDEs don't support this either (or not well). Also, in earlier days I have had not too good experiences with Subversive and Subclipse and always returned to doing svn from command line or other tools (e.g. TortoiseSVN). I looked a bit around in the internet and still find mainly bad remarks for those both plugins and suggestions not to do it from within Eclipse. Bye, Oliver ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Better Eclipse CDT support
Am 29.04.2011 20:49, schrieb Alexander Neundorf: On Friday 29 April 2011, Oliver Buchtala wrote: Am 29.04.2011 09:49, schrieb Eric Noulard: 2011/4/29 Oliver Buchtala oliver.bucht...@jku.at: As described before, I added links to the (main) project's source and build folder. You enable this with -DCDT_LINK_MAIN_SOURCE_FOLDERS=ON. For that to work properly, I strongly recommend to use Eclipse 3.7 M6 + CDT 8.0. @Alex: is there a way to provide --help assistance concerning such parameters with extra-generators? Hi guys, Just stepping in to say that documenting generator-specifics features is an issue CPack has as well. Read discussion on that topic here: http://public.kitware.com/Bug/view.php?id=10067 Currently I tried to put generator-specific doc. in CPackGenName.cmake file such that cmake --help-module CPackGenName will display the doc. the idea in the end would be to have cpack --help-generator GenName use the same mechanism to display the doc. may be we can design some unified way to documents such things for CMake/CPack/CTests. I know there are some (huge) bits of doc burried into the C++ code too but having a way to write some doc in separate files makes it easier to enhance the doc. Just throwing some ideas here. Hi Eric, thanks for your hint. I also vote for a unified approach. Personally, I think the doc for built-ins should reside in the source: no cluttering, and more uniqueness. But your suggestion is also reasonable. Would be awesome, if the doc could be taken from a comment block in the source file. Then it would be local and readable. But this is probably too difficult to achieve. All cmake docs are generated from the sources. There is a short doc for the generator, this is in cmExtraEclipseGenerator::GetDocumentation(). The variables are documented in cmDocumentVariables.cxx. The documentation for each module is at the top of the module itself. So if you put some documentation at the top of CMakeFindEclipseCDT4.cmake it will end up in the module documentation. Is this what you mean ? Alex Yep. Sounds great ;) ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Better Eclipse CDT support
Am 28.04.2011 22:57, schrieb Alexander Neundorf: On Wednesday 27 April 2011, Oliver Buchtala wrote: Forgot to feed the list... Am 27.04.2011 22:01, schrieb Alexander Neundorf: On Friday 22 April 2011, Oliver Buchtala wrote: ... Here we go: git://github.com/oliver/cmake_cdt7.git I have intensively worked with this generator the last days - and am not completely satisfied with it in the moment. But basically, it does what I want. I built and installed it. I'm actually not really using Eclipse much myself, e.g. so I have never used working sets before. I tried to load it via Project Explorer - Select Working Set - Window Working Set - Working set type: C/C++ and then selecting the builddir/eclipse/CMake.wst file. But now I'm not sure what to do with it. The normal targets and directory structure look like they did before, and in the eclipse/ directory there are a lot of empty directories starting with a @. So, how do I use it ? Alex Hi Alex, I have written down some things on http://edge.substance.io/#oliver/CMakeEclipseCDT7 I installed the plugin. Now I imported the working set CMake.wst instead of the project(s). I see three working sets: CMake, CMake/ALL and CMake/CTestDashboardTargets. When I select Top Level Elements - Projects, I see nothing from them. When I select Top Level Elements - Working sets, I see them, e.g. the CMake one. When I try to click it open, it is empty. If I right-click it and Go Into, the pane becomes empty. When I right-click and click Properties, it shows me a dialog with the existing (other) projects, no cmake among them, and no directories are checked. What am I doing wrong ? The wst file is attached. Alex Hi Alex, wst-file is allright and I see that all projects are generated :) Unfortunately, this working set stuff is yet a bit inconvenient, as it is not an Eclipse built-in. What you need to do: 0. Switch to C/C++ perspective (maybe this is the empty project observation you described?) 1. Import eclipse projects (all from the CDT_ECLIPSE_OUTPUT_DIR) - you see all projects flat side by side? 2. Import wst file 3. Goto 'Select Working Sets...' (in Project Explorer) 4. Select all (three) working sets 5. Goto 'Top Level Elements' (in Project Explorer) and activate 'Working Sets' Now you should see the projects within working sets Note1: almost all are in the CMake working sets, as FOLDERs are only set for MSVC generators Note2: once I experienced that the working sets plugin spoiled my workspace some how and I had import from scratch after deleting .metadata in workspace directory and restart eclipse and then redo that importing. Helps? I want to create an Eclipse Plugin which shall make all this more convenient and more automatically. Something like a CMake enabling 'Solution' file that manages imported projects and working sets etc... But yet I am a PDE beginner... so, this will take some more weeks... Bye, Oliver ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Better Eclipse CDT support
Am 29.04.2011 00:03, schrieb Oliver Buchtala: Am 28.04.2011 23:30, schrieb Oliver Buchtala: Am 28.04.2011 22:57, schrieb Alexander Neundorf: On Wednesday 27 April 2011, Oliver Buchtala wrote: Forgot to feed the list... Am 27.04.2011 22:01, schrieb Alexander Neundorf: On Friday 22 April 2011, Oliver Buchtala wrote: ... Here we go: git://github.com/oliver/cmake_cdt7.git I have intensively worked with this generator the last days - and am not completely satisfied with it in the moment. But basically, it does what I want. I built and installed it. I'm actually not really using Eclipse much myself, e.g. so I have never used working sets before. I tried to load it via Project Explorer - Select Working Set - Window Working Set - Working set type: C/C++ and then selecting the builddir/eclipse/CMake.wst file. But now I'm not sure what to do with it. The normal targets and directory structure look like they did before, and in the eclipse/ directory there are a lot of empty directories starting with a @. So, how do I use it ? Alex Hi Alex, I have written down some things on http://edge.substance.io/#oliver/CMakeEclipseCDT7 I installed the plugin. Now I imported the working set CMake.wst instead of the project(s). I see three working sets: CMake, CMake/ALL and CMake/CTestDashboardTargets. When I select Top Level Elements - Projects, I see nothing from them. When I select Top Level Elements - Working sets, I see them, e.g. the CMake one. When I try to click it open, it is empty. If I right-click it and Go Into, the pane becomes empty. When I right-click and click Properties, it shows me a dialog with the existing (other) projects, no cmake among them, and no directories are checked. What am I doing wrong ? The wst file is attached. Alex Hi Alex, wst-file is allright and I see that all projects are generated :) Unfortunately, this working set stuff is yet a bit inconvenient, as it is not an Eclipse built-in. What you need to do: 0. Switch to C/C++ perspective (maybe this is the empty project observation you described?) 1. Import eclipse projects (all from the CDT_ECLIPSE_OUTPUT_DIR) - you see all projects flat side by side? 2. Import wst file 3. Goto 'Select Working Sets...' (in Project Explorer) 4. Select all (three) working sets 5. Goto 'Top Level Elements' (in Project Explorer) and activate 'Working Sets' Now you should see the projects within working sets Note1: almost all are in the CMake working sets, as FOLDERs are only set for MSVC generators Note2: once I experienced that the working sets plugin spoiled my workspace some how and I had import from scratch after deleting .metadata in workspace directory and restart eclipse and then redo that importing. Helps? I want to create an Eclipse Plugin which shall make all this more convenient and more automatically. Something like a CMake enabling 'Solution' file that manages imported projects and working sets etc... But yet I am a PDE beginner... so, this will take some more weeks... Bye, Oliver FYI: I am currently struggling a bit with Eclipse's linked folders under Eclipse 3.6 + CDT 7.0.2. This has the consequence, that I can not add a link to PROJECT_SOURCE_DIR and PROJECT_BINARY_DIR without causing troubles with the CDT indexer. I'd really like to have a the global project similar to the project your generator creates. With Eclipse 3.7 and CDT 8 these problems seem to be resolved. So that feature is currently deactivated and I will make it switchable for edge-affine eclipse users. When the next version is released officially it's gonna be the default behavior. Bye, Oliver As described before, I added links to the (main) project's source and build folder. You enable this with -DCDT_LINK_MAIN_SOURCE_FOLDERS=ON. For that to work properly, I strongly recommend to use Eclipse 3.7 M6 + CDT 8.0. @Alex: is there a way to provide --help assistance concerning such parameters with extra-generators? Bye, Oliver ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Better Eclipse CDT support
Am 27.04.2011 21:28, schrieb Alexander Neundorf: On Monday 25 April 2011, Oliver Buchtala wrote: Am 20.04.2011 22:09, schrieb Alexander Neundorf: ... What would you expect there ? Some structure that gives me acces to the sources of the targets. I suppose, you try to achieve this with sub-projects, but it does not work properly in my case. How does it work not properly ? Don't you have project() calls or are they not created ? While creating a document on my generator implementation, I stumbled over the solution to this problem. [Subprojects] was empty in my setting because the generated link specifications have been invalid. Maybe, Eclipse CDT has changed here (?). You have to use 'locationURI' for virtual folders and 'location' for linked folders. I.e., specify a linked folder like that (in .cproject-file): ... linkedResources link name[Subprojects]/name type2/type locationURIvirtual:/virtual/locationURI /link link name[Subprojects]/LIBCURL/name type2/type locationD:/libraries/cmake-git/Utilities/cmcurl/location /link /linkedResources ... Does the attached patch fix this for you ? For me (Eclipse Helios under Linux) it doesn't make a difference. Alex Yep. This does under Windows as well. Bye, Oliver ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Better Eclipse CDT support
Am 20.04.2011 22:09, schrieb Alexander Neundorf: ... What would you expect there ? Some structure that gives me acces to the sources of the targets. I suppose, you try to achieve this with sub-projects, but it does not work properly in my case. How does it work not properly ? Don't you have project() calls or are they not created ? While creating a document on my generator implementation, I stumbled over the solution to this problem. [Subprojects] was empty in my setting because the generated link specifications have been invalid. Maybe, Eclipse CDT has changed here (?). You have to use 'locationURI' for virtual folders and 'location' for linked folders. I.e., specify a linked folder like that (in .cproject-file): ... linkedResources link name[Subprojects]/name type2/type locationURIvirtual:/virtual/locationURI /link link name[Subprojects]/LIBCURL/name type2/type locationD:/libraries/cmake-git/Utilities/cmcurl/location /link /linkedResources ... ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Better Eclipse CDT support
Am 20.04.2011 22:09, schrieb Alexander Neundorf: On Wednesday 20 April 2011, Oliver Buchtala wrote: Hi Alex, ... What would you expect there ? Some structure that gives me acces to the sources of the targets. I suppose, you try to achieve this with sub-projects, but it does not work properly in my case. How does it work not properly ? Don't you have project() calls or are they not created ? There is some link - but empty. I have exactly one project call (like I usually do). Is your build dir a subdir of the source dir ? Yes. In this case the link to CMAKE_SOURCE_DIR is not generated, otherwise there should be a link [Source directory]. It's a pity that Eclipse has such problems with out-of-source builds. Ok - that is the problem with my setting then. It's really Eclipse which would need some fixing here. It would just have to accept that the base source directory is not always the directory where the project file is located, but can be a directory specified in the project file. This would help a lot. See attachment: 2.4.8 CDT4 MinGW generator on CMake/Example, Eclipse Helios, CDT 7.0.2 All in all, this is not what a developer used to CDT wants to see ;) What I want to do: - generate projects for each target (like in VC generators) Can you please explain ? Do you want a separate build tree for each project ? Or just separate Eclipse project files for each target ? For each target. Like in MSVC. Are you sure people will want to import that many projects or can they be grouped in some way in a superproject ? Eclipse users are used to a flat multi-project layout. They use working sets to group projects. Actually, I am personally not the greatest friend of complete flat hierarchies - but this is actually the eclipse way. You may have a look at large Eclipse java projects, e.g. Eclipse itself. Importing all projects in a directory is a one-clicker. Though, they should not be nested for that feature to work. Hmm. So this would be one build tree (i.e. one CMakeCache.txt with a global Makefile-structure), and Eclipse-projects for each target, and a working set which groups these projects together ? Yep. One Make tree. And 'light-weight' eclipse projects as views on targets. Don't know. Maybe. Can you provide a screenshot of how this looks like ? Or maybe create a clone of the cmake git tree on gitorious or github and try to implement it there ? I have a working impl will push it on github tommorrow :) Cool :-) Here we go: git://github.com/oliver/cmake_cdt7.git I have intensively worked with this generator the last days - and am not completely satisfied with it in the moment. But basically, it does what I want. I did not completely base upon your implementation (generating project programmatically) but rather used a template approach. The templates are created manually from within eclipse... I'll try to improve my work a bit the next days... Or, how about instead of creating one project per target one project per project() call ? Hmm. Is it typical to have many project calls? I don't know whether it's typical. It also depends what you consider many ;-) I usually use project() for a somehow self-contained part of the build tree. I'll ping you tomorrow (after work). I won't be back before Monday. Alex Alright. Frohes Osterfest then ;) Bye, Oliver ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] Post-Build commands on custom targets are always executed?
Am 19.04.2011 16:10, schrieb David Cole:
On Mon, Apr 18, 2011 at 11:22 PM, Michael Hertling
mhertl...@online.de mailto:mhertl...@online.de wrote:
On 04/19/2011 02:17 AM, Oliver Buchtala wrote:
Am 18.04.2011 06:58, schrieb Michael Hertling:
On 04/16/2011 12:05 AM, Oliver Buchtala wrote:
Am 15.04.2011 23:48, schrieb Michael Hertling:
On 04/15/2011 11:22 PM, Oliver Buchtala wrote:
Hi,
I observe that a custom command attached to a custom target as
POST-BUILD is launched on every build.
Is that true? or is it a misconfiguration on my side?
Bye,
Oliver
A custom target is always out of date, i.e. it is always
rebuilt when
it is visited - as a prerequisite of another target or due to
the ALL
clause, e.g., and since the target has been rebuilt, each
associated
POST_BUILD custom command is rerun. Thus, the behaviour you
observed
is correct, expected and reasonable, IMO.
Regards,
Michael
Yep. That's reasonable.
Do have a suggestion how to get around a rerun of the post-build?
Prevent the custom target from being visited, i.e. from being
checked
if it's up to date since it will be found to be out of date, so the
immediately associated commands - if any - are run as well as the
associated POST_BUILD custom commands.
Or how would you do a post-build after custom-target without
being run
when custom-target actually did nothing,
What do you mean with a custom target that actually did
nothing? Not
visited or no own commands? In the former case, the associated
custom
commands are not run, of course, but in the latter case, it
does not
matter if there are immediately associated commands or not
since the
target will be considered as out of date and
rebuilt-without-op, and
its POST_BUILD custom commands will be run. In other words: A
custom
target - even without own commands - is not good for preventing its
custom commands from being run when the custom target is visited.
i.e., custom target depends on custom command that did nothing?
The same holds for this kind of dependency, i.e. the visited custom
target will be rebuilt regardless whether the prerequisite custom
command did do something or not, or do you still talk about the
custom-command-associated-with-custom-target dependency?
Alright. Then, no way to get what i want with custom targets.
I am asking, as I try to improve behavior with
UseJave.cmake::add_jar
(on stage::next) which creates a custom target.
E.g., after building the jar I want to copy the java archive into
another destination (not install).
OK, I see; in fact, this would be a good job for a POST_BUILD custom
command associated with the custom target. Thus, as you can't prevent
the custom command from being run on behalf of the custom target, you
should set up the command to do nothing if there's actually nothing to
do. E.g., you might use ${CMAKE_COMMAND} -E copy_if_different ... to
copy the updated-or-not-updated jar file, so the custom command is as
cheap as possible, although it always runs when the custom target is
examined. Moreover, ${CMAKE_COMMAND} -P ... and the IF() command's
EXISTS and IS_NEWER_THAN clauses possibly provide further approaches
w.r.t. your concern.
Regards,
Michael
As long as java support is on a weak basis (i.e., not built-in),
this
won't change...
Thank you for your help!
Bye,
Oliver
___
Powered by www.kitware.com http://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
This is how I would do it:
Why wouldn't you simply add *another* custom target that depends on
the output of a custom command, and then make that custom command's
output be your copy of the jar file, and then make the custom command
depend on the real jar file?
Then, the custom target would run always -- but it has no command,
so there's never anything to do, but when the custom command's depends
are out of date, it will execute, and the jar file will be copied...
If you have something that depends on a file, then it should nearly
always be a custom command.
Custom targets are best at simply collecting related custom commands
in. I've never found them that useful with commands associated
directly in the add_custom_target call.
HTH,
David
Re: [CMake] Post-Build commands on custom targets are always executed?
Am 18.04.2011 06:58, schrieb Michael Hertling: On 04/16/2011 12:05 AM, Oliver Buchtala wrote: Am 15.04.2011 23:48, schrieb Michael Hertling: On 04/15/2011 11:22 PM, Oliver Buchtala wrote: Hi, I observe that a custom command attached to a custom target as POST-BUILD is launched on every build. Is that true? or is it a misconfiguration on my side? Bye, Oliver A custom target is always out of date, i.e. it is always rebuilt when it is visited - as a prerequisite of another target or due to the ALL clause, e.g., and since the target has been rebuilt, each associated POST_BUILD custom command is rerun. Thus, the behaviour you observed is correct, expected and reasonable, IMO. Regards, Michael Yep. That's reasonable. Do have a suggestion how to get around a rerun of the post-build? Prevent the custom target from being visited, i.e. from being checked if it's up to date since it will be found to be out of date, so the immediately associated commands - if any - are run as well as the associated POST_BUILD custom commands. Or how would you do a post-build after custom-target without being run when custom-target actually did nothing, What do you mean with a custom target that actually did nothing? Not visited or no own commands? In the former case, the associated custom commands are not run, of course, but in the latter case, it does not matter if there are immediately associated commands or not since the target will be considered as out of date and rebuilt-without-op, and its POST_BUILD custom commands will be run. In other words: A custom target - even without own commands - is not good for preventing its custom commands from being run when the custom target is visited. i.e., custom target depends on custom command that did nothing? The same holds for this kind of dependency, i.e. the visited custom target will be rebuilt regardless whether the prerequisite custom command did do something or not, or do you still talk about the custom-command-associated-with-custom-target dependency? Alright. Then, no way to get what i want with custom targets. I am asking, as I try to improve behavior with UseJave.cmake::add_jar (on stage::next) which creates a custom target. E.g., after building the jar I want to copy the java archive into another destination (not install). As long as java support is on a weak basis (i.e., not built-in), this won't change... Thank you for your help! Bye, Oliver ___ 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-developers] Better Eclipse CDT support
Hi Alex, Am 17.04.2011 20:46, schrieb Alexander Neundorf: Hi, On Sunday 17 April 2011, Oliver Buchtala wrote: Hi, I like to get involved offering work on the Eclipse CDT generator. Currently, the generated project setting is not very Eclipse'ish. There have been some changes in the 2.8.x versions. You have 2.8.4 ? Yes. Actually current 'next' of stage. - one large project - linear build, i.e., build failure in early sub projects stops the whole chain You can change this e.g. by adding -k as CMAKE_ECLIPSE_MAKE_ARGUMENTS in the cmake cache. What does '-k' do? - project overview looks like navigator on cmake binary directory - source files can be found in 'includes' Can you please explain the two points above in more detail ? When I generate a CDT project, sources are in 'includes' (CDT built-in folder). The rest is the content of CMAKE_BINARY_DIR. See attachment: 2.4.8 CDT4 MinGW generator on CMake/Example, Eclipse Helios, CDT 7.0.2 typo: 2.8.4 All in all, this is not what a developer used to CDT wants to see ;) What I want to do: - generate projects for each target (like in VC generators) Can you please explain ? Do you want a separate build tree for each project ? Or just separate Eclipse project files for each target ? For each target. Like in MSVC. Are you sure people will want to import that many projects or can they be grouped in some way in a superproject ? Eclipse users are used to a flat multi-project layout. They use working sets to group projects. Actually, I am personally not the greatest friend of complete flat hierarchies - but this is actually the eclipse way. You may have a look at large Eclipse java projects, e.g. Eclipse itself. Importing all projects in a directory is a one-clicker. Though, they should not be nested for that feature to work. Another typical way to separate things is to have multiple workspaces. E.g. one for each large project. So IMO there are enough ways to structure views on very large projects. Another feedback story: At work, I suggested my coworkers to give eclipse+cmake a try (without trying it myself) as we have now a CMake setup and I am a fan of CDT. They stopped disappointed beeing confused by the project layout. They are used to MSVC and a bit to Codeblocks. And, trying it the first time (yesterday) I really felt similar. Perhaps, you can understand on the basis of my screenshot. - based upon makefile generator eclipse cdt projects can be based upon existing makefiles (e.g. in sub-dirs) - add folders: * src: using eclipse linked folder pointing to source location (CMAKE_CURRENT_SOURCE_DIR) * cmake: eclipse linked folder pointing to CMAKE_CURRENT_BINARY_DIR We have something like this in 2.8.4. I.e. there are linked folders for each project(), and one linked folder for CMAKE_SOURCE_DIR. I thought have seen this beeing deactivated in source code due to some issue filed on bugtracker? - add project dependencies for correct build order Having this would make the CDT generator beeing a serious citizen on the cmake generators list. Q's: - What is your opinion? A not-Makefile based native Eclipse project generator might also be an alternative, but requires more work. I think the Makefile based approach is very reasonable as it is really tightly integrated. Actually, there is not too much missing IMO. Per target project would bring a more intuitive relation between targets and projects. This is really what I want from the IDE setting. Otherwise I will use make on the shell. I would add a project per target based on make. Per project add only the one make target. And maybe add a global ALL project. Maybe also a ZERO_CHECK project all others depend on ... for checking on CMakeLists.txt changes. Another question: you call the generator CDT4. Current CDT is 7.0.2. Though, I find 'cdtBuilder version' in current .cproject. Is CDT4 'out-of-date' or are you referring to the version in xml? Ehmm, I mean this: ?fileVersion 4.0.0? storageModule moduleId=cdtBuildSystem version=4.0.0 Bye, Oliver ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[CMake] Post-Build commands on custom targets are always executed?
Hi, I observe that a custom command attached to a custom target as POST-BUILD is launched on every build. Is that true? or is it a misconfiguration on my side? Bye, Oliver ___ 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] Post-Build commands on custom targets are always executed?
Am 15.04.2011 23:48, schrieb Michael Hertling: On 04/15/2011 11:22 PM, Oliver Buchtala wrote: Hi, I observe that a custom command attached to a custom target as POST-BUILD is launched on every build. Is that true? or is it a misconfiguration on my side? Bye, Oliver A custom target is always out of date, i.e. it is always rebuilt when it is visited - as a prerequisite of another target or due to the ALL clause, e.g., and since the target has been rebuilt, each associated POST_BUILD custom command is rerun. Thus, the behaviour you observed is correct, expected and reasonable, IMO. Regards, Michael ___ 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 Yep. That's reasonable. Do have a suggestion how to get around a rerun of the post-build? Or how would you do a post-build after custom-target without being run when custom-target actually did nothing, i.e., custom target depends on custom command that did nothing? Bye, Oliver ___ 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] Overriding Win-Registry search in UseJNI.cmake
Hello, I am working with CMake 2.8 and using UseJNI.cmake I have a JDK installed locally (registered in Win-Registry) but want to configure a project to use a different JDK lying on my disk. Looking at UseJNI.cmake I find that the environment variable JAVA_HOME could be handy, but unfortunately UseJNI prefers the Windows-Registry entries above all other search paths. Did I miss something? Shall I file an issue? Oliver ___ 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] Overriding Win-Registry search in UseJNI.cmake
Am 05.04.2011 13:12, schrieb Oliver Buchtala: Hello, I am working with CMake 2.8 and using UseJNI.cmake I have a JDK installed locally (registered in Win-Registry) but want to configure a project to use a different JDK lying on my disk. Looking at UseJNI.cmake I find that the environment variable JAVA_HOME could be handy, but unfortunately UseJNI prefers the Windows-Registry entries above all other search paths. Did I miss something? Shall I file an issue? Oliver Sorry, the macro file is called FindJNI.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
Re: [CMake] Overriding Win-Registry search in UseJNI.cmake
Am 05.04.2011 16:33, schrieb David Cole: On Tue, Apr 5, 2011 at 7:16 AM, Oliver Buchtala oliver.bucht...@jku.at mailto:oliver.bucht...@jku.at wrote: Am 05.04.2011 13:12, schrieb Oliver Buchtala: Hello, I am working with CMake 2.8 and using UseJNI.cmake I have a JDK installed locally (registered in Win-Registry) but want to configure a project to use a different JDK lying on my disk. Looking at UseJNI.cmake I find that the environment variable JAVA_HOME could be handy, but unfortunately UseJNI prefers the Windows-Registry entries above all other search paths. Did I miss something? Shall I file an issue? Oliver Sorry, the macro file is called FindJNI.cmake. ___ Powered by www.kitware.com http://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 The only find_* calls I see in FindJNI.cmake are: FIND_LIBRARY(JAVA_AWT_LIBRARY jawt FIND_LIBRARY(JAVA_JVM_LIBRARY NAMES jvm JavaVM FIND_PATH(JAVA_INCLUDE_PATH jni.h FIND_PATH(JAVA_INCLUDE_PATH2 jni_md.h FIND_PATH(JAVA_AWT_INCLUDE_PATH jawt.h If you want to override the default locations to find a specific installation of java stuff, just set those variables in your cache to point to the right stuff before calling find_package(JNI). For example: set(JAVA_AWT_LIBRARY /full/path/to/libjawt.a CACHE FILEPATH jawt library) find_package(JNI) If a variable is already set before calling a find_* command, then the find is a no-op and it trusts that you've set it correctly. HTH, David Hi David, ok. I thought it could even be easier ;) If I disable the win-Registry lookup stuff and set JAVA_HOME appropriately then everything is found perfectly. And if disabling would be just changing the order of search paths this would be more control for me and still powerful (i.e., when not using JAVA_HOME). Nevertheless, I can also live with your suggestion... Thank you, Oliver ___ 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] Overriding Win-Registry search in UseJNI.cmake
Am 05.04.2011 17:11, schrieb Oliver Buchtala: Am 05.04.2011 16:33, schrieb David Cole: On Tue, Apr 5, 2011 at 7:16 AM, Oliver Buchtala oliver.bucht...@jku.at mailto:oliver.bucht...@jku.at wrote: Am 05.04.2011 13:12, schrieb Oliver Buchtala: Hello, I am working with CMake 2.8 and using UseJNI.cmake I have a JDK installed locally (registered in Win-Registry) but want to configure a project to use a different JDK lying on my disk. Looking at UseJNI.cmake I find that the environment variable JAVA_HOME could be handy, but unfortunately UseJNI prefers the Windows-Registry entries above all other search paths. Did I miss something? Shall I file an issue? Oliver Sorry, the macro file is called FindJNI.cmake. ___ Powered by www.kitware.com http://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 The only find_* calls I see in FindJNI.cmake are: FIND_LIBRARY(JAVA_AWT_LIBRARY jawt FIND_LIBRARY(JAVA_JVM_LIBRARY NAMES jvm JavaVM FIND_PATH(JAVA_INCLUDE_PATH jni.h FIND_PATH(JAVA_INCLUDE_PATH2 jni_md.h FIND_PATH(JAVA_AWT_INCLUDE_PATH jawt.h If you want to override the default locations to find a specific installation of java stuff, just set those variables in your cache to point to the right stuff before calling find_package(JNI). For example: set(JAVA_AWT_LIBRARY /full/path/to/libjawt.a CACHE FILEPATH jawt library) find_package(JNI) If a variable is already set before calling a find_* command, then the find is a no-op and it trusts that you've set it correctly. HTH, David Hi David, ok. I thought it could even be easier ;) If I disable the win-Registry lookup stuff and set JAVA_HOME appropriately then everything is found perfectly. And if disabling would be just changing the order of search paths this would be more control for me and still powerful (i.e., when not using JAVA_HOME). Nevertheless, I can also live with your suggestion... Thank you, Oliver Hi David, Thinking it over again, I am getting to like it less... Setting these variables is in fact the stuff that FindJNI does. For now I will live with a monkey patched version that allows disabling the registry search stuff. Is this an option for the core FindJNI.cmake too - i.e., introducing a means to disable win registry search? Bye, Oliver ___ 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] How to USE_FOLDERS correctly?
Hello, I have problems using the project folder feature described in the documentation for CMake 2.8.4 (http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_global:USE_FOLDERS) The very first command in my configuration is set(GLOBAL PROPERTY USE_FOLDERS ON) later, I define target properties, as so set_property(TARGET myCore PROPERTY FOLDER Core) I am using cmake --version cmake version 2.8.4 under Windows with generator 'Visual Studio 9 2008'. I am working with a VS Professional version (not Express). Everything is generated without errors or warnings, but the generated solution does not contain anything like solution folders. What could be my problem? Bye, Oliver ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to USE_FOLDERS correctly?
Am 18.03.2011 18:31, schrieb Robert Bielik: Hi Oliver, I use this feature and only thing that differs for me is that I do: SET_TARGET_PROPERTIES( myCore PROPERTIES FOLDER Core ) Hope that helps, /Rob ___ 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 Hi Rob, I tried this as well - unfortunately does not help. But thanks anyway Bye, Oliver ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to USE_FOLDERS correctly?
Am 18.03.2011 18:51, schrieb David Cole: On Fri, Mar 18, 2011 at 1:15 PM, Oliver Buchtala oliver.bucht...@jku.at wrote: Hello, I have problems using the project folder feature described in the documentation for CMake 2.8.4 (http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_global:USE_FOLDERS) The very first command in my configuration is set(GLOBAL PROPERTY USE_FOLDERS ON) Typo... you mean: set_property(GLOBAL PROPERTY USE_FOLDERS ON) (You're setting a CMake variable named GLOBAL there, not a global property...) Cheers, David Hi David, that's it! Thanks, Oliver ___ 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
