I have a collection of C++ projects that use managed makefiles inside Eclipse. I build them all, and run an existing deploy script to place all the compiled results into a target directory on the system.
I'd like a way to automate the build process without having to open the IDE, but due to external constraints from the project owner, I have to use managed make.
Once I kickoff a build for the first time inside the Eclipse IDE, the Debug / Release directories are created, and the makefiles are autogenerated. Once they are all present, I can call make from the command line, across all the projects, run an overall deploy script, etc. This will work up until the point that code changes would cause the makefiles to differ (adding/removing source files, or changing build parameters) The big problem with this is that it requires me to open eclipse and manually cause the generation of the makefiles.
I see two options:
Check the generated makefiles into revsion control (even though they're generated, I know), and commit them whenever they, after generation, have differed from the previous content.
Find a way to either open eclipse in a scriptable way, and cause makefile generation, or to find some alternate way to generate the makefiles from the .project files.
Option 1 is obviously subject to problems if I or other developers don't remember to commit the files, or if we update the Debug makefile but not the Release makefile, etc. It also makes me feel dirty to commit a generated file.
Option 2 seems much better, if its feasible.
Does a method to do option 2 exist? Are there other options I haven't considered?
I recognize similarity with a continouous integration server, but This is not the same use case. Essentially I'm building a package that gets installed on a development system as a testing release of a system library. So I'm operating as a developer, I just want to reduce variance out of the deploy process itself.
Related
I have a standard C project in Eclipse CDT. Naturally it uses make. I have decided to add some JSON support to my application to be able to load/save its configuration in a readable format that the user (if such desire occurs) can alter those manually and/or through an external tool. I've looked up two options so far namely Jansson and Json-C. The problem is that both are using cmake, which, if I recall correctly, can be imported in Eclipse CDT without problems (though in itself CDT can't create cmake projects).
I was thinking of adding a script for the pre-build step of my project that runs cmake (as an external command) and sets up the JSON library (static and/or dynamic) so that when the build process of my projects starts the library file will be available.
Is there a better way to combine a cmake with a make project in Eclipse CDT? I know that cmake basically generates a Makefile but I've never done such a combination before.
Even if there is a JSON C library somewhere out ther that uses make (I'm 99.9% sure there is such thing :D) I'd still like to know how to tackle this situation.
I have a Makefile project in Eclipse CDT, which is comprised of dozens of source files. I normally build the project with the -j option, so the make does parallel builds. Sometimes I need the serial build. Thus, I defined two configurations, differing in that option.
If an error occurs while doing a parallel build, then sometimes it is hard to follow the diagnostics messages due to make's interleaved output from all processes. So next thing I do is try the serial build configuration.
The problem is that unless I actually change a file, or clean the project, no build is performed. as Eclipse assumed nothing has changed (which is technically right, but in a C/C++ Project, it will know the build was not complete and attempt to rebuild [at least IIRC]).
How can I make Eclipse to run the make command if I changed a configuration, but not a file?
I recently joined a large C++ project that where the codebase is housed in Clearcase. The primarly build system is make, which is also in Clearcase. The builds are unwieldy and long, so I would like to use the Clearcase plugin for Eclipse to select a small subset of files for an Eclipse CDT project I can use as an alternative build system for active development and debugging.
Is there a robust way to do this? The Eclipse setup is Helios SR2 running on Linux.
First, a general advice: use snapshot views, not dynamic views, for your compilation, especially if you need to access (for linking purposes for instance) large binaries: the compilation will be faster.
Plus, in a snapshot view, with its loading rules, you will select the subset of files you actually need to see and work on.
The other way to fasten a compilation (if you haven't the need to access large binaries), is to use dynamic view this time, but with clearmake instead of make, allowing for ClearCase to record the DO (Derived Object): see "ClearCase Build Concepts"
In answer to my own question, one can create a project by way of File > New > "Makefile Project with Existing Code". The "Import Existing Code" dialog appears where one can enter a root folder path.
I'm trying to convert a Netbeans 6.9.1 project into a scripted build (without netbeans). Of course, it fails (or I wouldn't be asking for help).
In the failure it says that the org.apache.commons.httpclient package does not exist. (Of course, it worked when we ran the build in Netbeans).
Now I know exactly where the commons-httpclient.jar file is located in my project structure, but I can't seem to tell it to the compiler via the ant build files and the netbeans property files.
Perhaps related to this is when I ran "ant -v" to build my software, it said,
Property lib.mystuff.classpath has not been set. This variable is important, I guess, because
the file nbproject/project.properties uses lib.mystuff.classpath in its definition of javac.classpath, which of course tells the Java compiler where to find the JARs.
So...when moving a Netbeans project to a netbeans-independent scripted build, how can the build script set these properties? Also, how can I ensure that the jar file gets included in the ant build?
I appreciate any help I can get, as I am a Java newbie.
UPDATE AFTER ACCEPTING ANSWER FROM vkraemer:
There are a few best practices for build scripts for production software:
Put everything needed for a build under a single directory tree. (Netbeans = fail)
Put everything in source code control. (I did that)
The first line of the build script should clear all environment variables.
The next section of the build script should explicitly set all environment variables to values which are known to work.
The next part of the build should be able to execute using command-line programs such as javac, ant, cc, etc, and must not depend on firing up an IDE such as Eclipse or Netbeans.
It is a shame that Netbeans makes this hard.
I did a quick look in a Java Application project and found the following...
javac.classpath = ${libs.MyStuff.classpath}
libs.MyStuff.classpath is defined in %HOME%/.netbeans/6.9.1/build.properties.
You may be able to get by doing the following...
ant -Dlibs.MyStuff.classpath=c:\a\b\c.jar
You would need to do more if you have multiple jar files in the MyStuff library that you created in NetBeans.
I have a bit of code for a dll that is needed by two or more projects in eclipse. Currently each project has a copy of the code and builds the DLL separately. I want to separate the dll code into a separate eclipse project so there is a common location. But I want to avoid the situation where we have to build the dll in the one project, then copy the dll back to the other projects and check the dll to each respective project. This will create a dll for each project that isn't traceable to the exact code that it was built with.
Is there a way to somehow symbolically link the dlls to another eclipse project that is using CVS as the version control system so that it is possible to tell which version of the code was used to create the dll? Am I making this too complicated or missing something obvious?
I thought about working sets in the package manager for eclipse, but I have to investigate more on how to use them with CVS to avoid making it a nightmare for the next person who checks it out and can't figure out why their project won't compile.
Thanks.
What about creating a new folder in a separate project. In the advanced section of creating a new folder there is an option to link to another location on the file system.
Or you could also create a container project that makes use of a projectset.psf file. Have the projectset file link to the different projects in your repository. When you want to check out that project, check out the container instead and right click on the projectset file and select Import Project Set...
If you are working with one workspace, you end up with three projects, each mirrored in CVS: One is the dll, the others are the projects using the dll (configured as a project dependency of these projects upon the dll project).
With three projects I wouldn't aim for working sets - they are good for managing a lot of projects within one workspace, for three projects, I'd consider them overkill. I usually tend to aim for several workspaces instead of working sets.
Regarding the next person working with these projects: You need to keep some kind of documentation about how to setup your projects. You might say that your eclipse project files do just that (as they define a project dependency upon another project) but this is for the machine - humans tend to like other communication means.
If you are worried about changes to the dll being incompatible to one project (because the person applying these changes doesn't care about the other project), aim for a build server. This will build all projects and dependent projects whenever something under version control changes, run all tests, provide a build number and package it all ready for use. This way you can be sure that - whatever is in your deliverable - can be reproduced, because the buildserver is not able to make local (uncommitted) changes to the code. Also a buildserver will signal failure (either broken API or broken tests) at the moment of the last commit (well - a few minutes later) and place the burden of repairing the damage on the one causing the damage.