Re: [cmake-developers] Better Eclipse CDT support
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 :) /me is happy... will use it more and see how it behaves when the CMakeLists.txt change :D Cheers, /Manuel Bye, Oliver PS: I have developed and tested under Ubuntu LTS 10.04 + Eclipse 3.7 M6 + CDT 8.0 M6. ___ 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
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. /me is happy... will use it more and see how it behaves when the CMakeLists.txt change :D Cheers, /Manuel Bye, Oliver PS: I have developed and tested under Ubuntu LTS 10.04 + Eclipse 3.7 M6 + CDT 8.0 M6. ___ 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 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
On Wednesday 27 April 2011, you wrote: 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. Ok. I pushed this now to next, should be in 2.8.5. Alex ___ 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
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 ___ 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
On Saturday 30 April 2011, Oliver Buchtala wrote: Am 29.04.2011 21:45, schrieb Manuel Klimek: On Fri, Apr 29, 2011 at 11:55 AM, Alexander Neundorf neund...@kde.org wrote: On Thursday 28 April 2011, Oliver Buchtala wrote: ... 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? I have to import all the projects in eclipse/ manually one by one ? Nope, you just go to the toplevel directory, and eclipse will import recursively. Ah, I didn't know that. 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... That sounds like a great plan :-) But, for me, the thing which sucks by far most about the Eclipse generator, is that Eclipse has these problems with out-of-source building. AFAIK Eclipse expects that the project file is at the root of the source tree, and that e.g. also the svn etc. directories are in this tree. 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 ? For me Oliver's eclipse generator actually works with out-of-source builds. (eclipse 3.7, CDT 8). If I remember correctly the main thing to look out for is to put the workspace outside of both the source and the cmake build directory. Actually, *only* out-of-tree works well - unfortunately even (out-of-tree)^2 is necessary ;) The proposed solution is pretty similar to that generated for Visual Studio using virtual folders for structure and explicit referenced files. There are two options when importing generated eclipse projects: 1. Create out-of-every-tree using CDT_ECLIPSE_OUTPUT_DIR, then easy import by one click (ehm... at least O(1)) ;) 2. do not use CDT_ECLIPSE_OUTPUT_DIR? then make sure you copy the projects into your workspace (by activating a checkbox in the dialog). Though, I do not recomment as reconfigure won't affect your projects then. Unfortunately the following is not working (would be my favorite): proj-root - src ... - build - eclipse-prj - eclipse-linked folder to proj-root/ together with using proj-root/build as eclipse workspace. It is not allowed to have 'active' projects in some sub-dir of linked folders, or in other words, to link to parent-folders from eclipse proj. So how should the directory layout look like ? I currently do SOMEDIR/foo-src/ SOMEDIR/foo-build/ and there your new generator creates a SOMEDIR/foo-build/eclipse/ directory. Alex ___ 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
On Thursday 28 April 2011, Oliver Buchtala wrote: ... 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? I have to import all the projects in eclipse/ manually one by one ? I mean, there are twenty or more, I didn't count. I don't really feel like doing this. 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... That sounds like a great plan :-) But, for me, the thing which sucks by far most about the Eclipse generator, is that Eclipse has these problems with out-of-source building. AFAIK Eclipse expects that the project file is at the root of the source tree, and that e.g. also the svn etc. directories are in this tree. Now a golden rule of cmake is to never generate stuff into the source dir, but always only into the binary dir. Otherwise it is not really possible to have multiple build dirs for one source dir. So, if you think about starting to work on Eclipse, it would be *great* if you could try to make Eclipse support project root dir != dir of the project file, i.e. out-of-source builds. Alex ___ 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
On Fri, Apr 29, 2011 at 11:55 AM, Alexander Neundorf neund...@kde.org wrote: On Thursday 28 April 2011, Oliver Buchtala wrote: ... 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? I have to import all the projects in eclipse/ manually one by one ? Nope, you just go to the toplevel directory, and eclipse will import recursively. I mean, there are twenty or more, I didn't count. I don't really feel like doing this. 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... That sounds like a great plan :-) But, for me, the thing which sucks by far most about the Eclipse generator, is that Eclipse has these problems with out-of-source building. AFAIK Eclipse expects that the project file is at the root of the source tree, and that e.g. also the svn etc. directories are in this tree. For me Oliver's eclipse generator actually works with out-of-source builds. (eclipse 3.7, CDT 8). If I remember correctly the main thing to look out for is to put the workspace outside of both the source and the cmake build directory. Cheers, /Manuel Now a golden rule of cmake is to never generate stuff into the source dir, but always only into the binary dir. Otherwise it is not really possible to have multiple build dirs for one source dir. So, if you think about starting to work on Eclipse, it would be *great* if you could try to make Eclipse support project root dir != dir of the project file, i.e. out-of-source builds. Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers ___ 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
Pulling in a few more people (suggested audience from Sergey), please tell me if I'm CC'ing a list that doesn't make sense. Context: Oliver is currently working on making eclipse support for CMake a lot better. I heard that Andrew is working on configuration of includes and defines in eclipse, so there might be potential for coordinating efforts to make eclipse and cmake work better together and provide a really nicely integrated development setup. Cheers, /Manuel On Thu, Apr 28, 2011 at 3:03 PM, Oliver Buchtala oliver.bucht...@jku.at wrote: 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 ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers ___ 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
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 ?xml version=1.0 encoding=UTF-8? workingSets workingSet editPageId=org.eclipse.cdt.ui.CElementWorkingSetPage id=CMake label=CMake name=CMake item factoryID=org.eclipse.cdt.ui.PersistableCElementFactory path=/cmForm type=4/ item factoryID=org.eclipse.cdt.ui.PersistableCElementFactory path=/cmForm type=4/ item factoryID=org.eclipse.cdt.ui.PersistableCElementFactory path=/cmcompress type=4/ item factoryID=org.eclipse.cdt.ui.PersistableCElementFactory path=/cmcompress type=4/ item factoryID=org.eclipse.cdt.ui.PersistableCElementFactory path=/cmexpat type=4/ item factoryID=org.eclipse.cdt.ui.PersistableCElementFactory path=/cmexpat type=4/ item factoryID=org.eclipse.cdt.ui.PersistableCElementFactory path=/cmzlib type=4/ item factoryID=org.eclipse.cdt.ui.PersistableCElementFactory path=/cmzlib type=4/ item factoryID=org.eclipse.cdt.ui.PersistableCElementFactory path=/uninstall type=4/ item factoryID=org.eclipse.cdt.ui.PersistableCElementFactory path=/cmsys type=4/ item factoryID=org.eclipse.cdt.ui.PersistableCElementFactory path=/cmsys type=4/ item factoryID=org.eclipse.cdt.ui.PersistableCElementFactory path=/cmsysTestDynload type=4/ item factoryID=org.eclipse.cdt.ui.PersistableCElementFactory path=/cmsysTestDynload type=4/ item factoryID=org.eclipse.cdt.ui.PersistableCElementFactory path=/cmsysTestProcess type=4/ item factoryID=org.eclipse.cdt.ui.PersistableCElementFactory path=/cmsysTestProcess type=4/ item factoryID=org.eclipse.cdt.ui.PersistableCElementFactory path=/cmsysTestSharedForward type=4/ item factoryID=org.eclipse.cdt.ui.PersistableCElementFactory path=/cmsysTestSharedForward type=4/ item factoryID=org.eclipse.cdt.ui.PersistableCElementFactory path=/cmsysTestsC type=4/ item factoryID=org.eclipse.cdt.ui.PersistableCElementFactory path=/cmsysTestsC type=4/ item factoryID=org.eclipse.cdt.ui.PersistableCElementFactory path=/cmsysTestsCxx type=4/ item factoryID=org.eclipse.cdt.ui.PersistableCElementFactory path=/cmsysTestsCxx type=4/ item factoryID=org.eclipse.cdt.ui.PersistableCElementFactory path=/cmsys_c type=4/ item factoryID=org.eclipse.cdt.ui.PersistableCElementFactory path=/cmsys_c type=4/ item factoryID=org.eclipse.cdt.ui.PersistableCElementFactory path=/cmzlib type=4/ item factoryID=org.eclipse.cdt.ui.PersistableCElementFactory path=/cmzlib type=4/ item factoryID=org.eclipse.cdt.ui.PersistableCElementFactory path=/LIBCURL type=4/ item factoryID=org.eclipse.cdt.ui.PersistableCElementFactory path=/LIBCURL type=4/ item factoryID=org.eclipse.cdt.ui.PersistableCElementFactory path=/cmcurl type=4/ item factoryID=org.eclipse.cdt.ui.PersistableCElementFactory path=/cmcurl type=4/ item factoryID=org.eclipse.cdt.ui.PersistableCElementFactory path=/cmcompress type=4/ item factoryID=org.eclipse.cdt.ui.PersistableCElementFactory
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
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
diff --git a/Source/cmExtraEclipseCDT4Generator.cxx b/Source/cmExtraEclipseCDT4Generator.cxx
index c4ea425..8e26b8e 100644
--- a/Source/cmExtraEclipseCDT4Generator.cxx
+++ b/Source/cmExtraEclipseCDT4Generator.cxx
@@ -403,7 +403,7 @@ void cmExtraEclipseCDT4Generator::CreateProjectFile()
// for each sub project create a linked resource to the source dir
// - only if it is an out-of-source build
this-AppendLinkedResource(fout, [Subprojects],
- virtual:/virtual);
+ virtual:/virtual, true);
for (std::mapcmStdString, std::vectorcmLocalGenerator* ::const_iterator
it = this-GlobalGenerator-GetProjectMap().begin();
@@ -1082,17 +1082,24 @@ void cmExtraEclipseCDT4Generator
void cmExtraEclipseCDT4Generator
::AppendLinkedResource (cmGeneratedFileStream fout,
const std::string name,
-const std::string path)
+const std::string path,
+bool isVirtualFolder)
{
+ const char* locationTag = location;
+ if (isVirtualFolder) // ... and not a linked folder
+{
+locationTag = locationURI;
+}
+
fout
\t\tlink\n
\t\t\tname
cmExtraEclipseCDT4Generator::EscapeForXML(name)
/name\n
\t\t\ttype2/type\n
-\t\t\tlocationURI
+\t\t\t locationTag
cmExtraEclipseCDT4Generator::EscapeForXML(path)
- /locationURI\n
+ / locationTag \n
\t\t/link\n
;
}
diff --git a/Source/cmExtraEclipseCDT4Generator.h b/Source/cmExtraEclipseCDT4Generator.h
index 99e69c4..a683731 100644
--- a/Source/cmExtraEclipseCDT4Generator.h
+++ b/Source/cmExtraEclipseCDT4Generator.h
@@ -87,7 +87,8 @@ private:
static void AppendLinkedResource (cmGeneratedFileStream fout,
const std::string name,
-const std::string path);
+const std::string path,
+bool isVirtualFolder = false);
bool AppendOutLinkedResource(cmGeneratedFileStream fout,
const std::string defname,
___
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-developers] Better Eclipse CDT support
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 ? 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 :-) 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 ___ 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
Hi Oliver,
On Sunday 17 April 2011, Oliver Buchtala wrote:
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?
Continue building other targets if some targets failed.
- 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
I guess there is a
include_directories(${CMAKE_SOURCE_DIR})
or something similar in the project, so this directory appears
under Includes.
folder). The rest is the content of CMAKE_BINARY_DIR.
Yes, plus the links to the sub projects.
What would you expect there ?
Is your build dir a subdir of the source dir ?
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.
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 ?
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 ?
Or, how about instead of creating one project per target one project per
project() call ?
...
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.
This is because it was 4.0 when the generator was started.
The name simply was not changed since then.
Alex
___
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
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 ? - 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. - 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 ? 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 ? Are you sure people will want to import that many projects or can they be grouped in some way in a superproject ? - 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. - 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. - Stage access? - Collaborators? Author of CDT4 generator? I'm mainly maintaining it. Alex ___ 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
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
