Closed tcies closed 10 years ago
@tcies This is great! Thank you!
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.
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.
@mbuerki did you see this? Thanks @tcies !
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
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?
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?
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.
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?
Ok, I've pushed my alpha version : caf13bf129a7b09. Works for me.
great stuff! thanks hannes!
I used it several times now. Works for me flawlessly. I even improved it a bit already (b330e2612546788b0d67cb081b0b391f512e833a).
Nope, it was 1e4c9dcd290a530869e4f6c56059558ff97ad1da.
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).
Resolved due to "eclipsify"
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.