ethz-asl / programming_guidelines

This repository contains style-guides, discussions, eclipse/emacs auto-formatter for commonly used programming languages
139 stars 38 forks source link

FYI: added documentation on how to make eclipse projects from catkin packages #19

Closed tcies closed 10 years ago

tcies commented 10 years ago

https://github.com/ethz-asl/programming_guidelines/wiki/Catkin-Eclipse in https://github.com/ethz-asl/programming_guidelines/wiki#ide-integration Maybe you'd want to review. Thanks @markusachtelik , @simonlynen for the input to this.

simonlynen commented 10 years ago

@tcies This is great! Thank you!

simonlynen commented 10 years ago

One nit: for the tests, you can also change the build-command and put make run_tests instead of make, so you don't have to go through the shell script.

tcies commented 10 years ago

I tried "make run_tests" by itself, but it didn't work for me - so, inspired by Markus' "eclipsemake" script I wrote a similar script for the tests that sources the ros setup - run_tests seems to rely on ros configuration unlike "make" by itself.

furgalep commented 10 years ago

@mbuerki did you see this? Thanks @tcies !

tcies commented 10 years ago

NB wrote how to make default build robust to changes in CMakeLists, need to source ROS. See https://github.com/ethz-asl/programming_guidelines/wiki/Catkin-Eclipse#compilation-scripts

mbuerki commented 10 years ago

by the way, so that people don't have to redo the same steps over and over again, would it make sense to check in some of the eclipse project files? of course, they must not contain local paths, but I don't think they do. like language.settings.xml for example.

or is that a bad idea?

HannesSommer commented 10 years ago

I think, we should follow that simplification idea somehow. It's such a pain to do that for a lot of projects.

I guess ideal would be to write a script that generates them (based on some templates, maybe provided by the user of the script and containing user specific stuff). So at least a kind of replacements for the cmake generators. Has somebody ever tried to write such a generator? Does somebody know reasons why that won't work or will be too complicated?

tcies commented 10 years ago

Completely agree. I skeemed only a little bit how that would be done, and it seems slightly unpleasant though. Here's how CMake does it: https://github.com/Kitware/CMake/blob/ad9f0d831e6522d9606bab7ae08559cebeed83ce/Source/cmExtraEclipseCDT4Generator.h and https://github.com/Kitware/CMake/blob/5376151aa1d724b6d7ddef8d2e521d97cbfa74ae/Source/cmExtraEclipseCDT4Generator.cxx (they don't even XML) Last time I checked, .project and .cproject didn't contain local paths, but .settings did. Maybe those paths could be expressed relatively, though.

HannesSommer commented 10 years ago

Thanks for looking into that.

I've checked the eclipse project files. In one project the file .csettins/cdt.managedbuild.toolchain.gnu.base.1560693392_cdtBuildSystem contains the working directory of the make process - as absolute path. In another it was the .cproject file! So we already have three interpretation of the recipe that lead to quite different configurations :).

But anyway I guess these generators are to complex for the moment.

But it is probably quite simple to take an existing working project as template and instantiate it for another project by just replacing the corresponding relative paths in the catkin workspace. That should work for other projects in the same catkin workspace at least and could already save a lot of nasty work. I'll just tried that on a project. On the command my first try was 3 commands... I guess I will just write that script for a start. Btw. it worked perfectly so far.

Any concerns?

HannesSommer commented 10 years ago

Ok, I've pushed my alpha version : caf13bf129a7b09. Works for me.

mbuerki commented 10 years ago

great stuff! thanks hannes!

HannesSommer commented 10 years ago

I used it several times now. Works for me flawlessly. I even improved it a bit already (b330e2612546788b0d67cb081b0b391f512e833a).

HannesSommer commented 10 years ago

Nope, it was 1e4c9dcd290a530869e4f6c56059558ff97ad1da.

HannesSommer commented 10 years ago

I would recommend putting a "$@" at the end of the make lines of the eclipsemake files. make VERBOSE=1 -j8 $@

This way e.g. a "Clean project" does the right thing - very useful for the initial discover the include paths (instead of deleting the build folder).

furgalep commented 10 years ago

Resolved due to "eclipsify"

https://github.com/ethz-asl/eclipsify