Hacker News new | ask | show | jobs
by crpatino 3474 days ago
> The build system lets me forget entierly about "how am I going to write my tup/make/cmake/anything file" as it just works when I click go.

This is a bug, not a feature. Or rather, it is extremely easy for this to result in subtle "works on my machine" scenarios.

1. If you just "click & go", you are foresaking the ability to have automated builds.

2. If you implement the automated build independently from the IDE, you will end up in a setting where the developer makes changes to the IDE settings that are not reflected in the automated build. In a good day, this will result in broken builds. On a bad day, you will have bugs that are imposible to reproduce because the build QA uses is not the same as the build Development uses, even if they both come from the same SVCS. On an ugly day, you ship to your customers a binary version of the product that neither QA nor Development have ever tested before.

3. Not to mention that if you have no version control of the IDE settings, every developer has a slightly different build of the project, one that mostly works, until it does not. See the problems in #2 and extrapolate.
1 comments
gravypod 3473 days ago
> 1. If you just "click & go", you are foresaking the ability to have automated builds.

This is incorrect. Eclipse will generate ANT files that are usable via TeamCity.

> 2. If you implement the automated build independently from the IDE, you will end up in a setting where the developer makes changes to the IDE settings that are not reflected in the automated build. In a good day, this will result in broken builds. On a bad day, you will have bugs that are imposible to reproduce because the build QA uses is not the same as the build Development uses, even if they both come from the same SVCS. On an ugly day, you ship to your customers a binary version of the product that neither QA nor Development have ever tested before.

Again, just keep your ANT file in your source tree and export it after every change. This require far less maintenance then Make or cmake.

> 3. Not to mention that if you have no version control of the IDE settings, every developer has a slightly different build of the project, one that mostly works, until it does not. See the problems in #2 and extrapolate.

The build settings are stored in the project files. When you download the project and import it into Eclipse your build enviroment is kept in line.

In larger projects I use a CompanyLibraries project and inside it I have 1) all libraries, sources, and documents neatly organized along with all binaries involved with that library (so if it needs to import a .so or .dll it's there) and the IDE-Bootstrap process:

   1. Go into your settings and import *.userlibraries
   2. Go to your settings and import cleanup.xml
   3. Go to your settings and import codetemplates.xml 
   4. Go to your settings and import format.xml
You don't need to import the generated ant build system. You can right click it and run the build & tests from there.

After you do this you have complete autocompletion for every library we use. If needed you can cntrl-click to view source of a library, and it will work on your system even if you have windows or linux (because of the way I setup my .userlibraries). These are some from what I've seen the "little known" Eclipse goodies for collaboration.

Could it be better? Yes I'd like to eventually write an eclipse plugin that will automatically import these on a project by project basis then just make a git submodule in each of my projects that includes the global configs to make sure I still only have one.

link