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.
Related
I want to use CDT parser in a project. The project would be a command-line, stand-alone project, i.e., not an Eclipse plugin.
All solutions that I've seen requires using a IWorkspace. But, I want to use the CDT parser on single files outside eclipse. Is there any way to do that?
It depends what you mean by "without Eclipse".
CDT's code is built on top of the Eclipse Platform, so you're going to need to be running an application that includes the Eclipse Platform. However, there's no reason that application can't be a command-line application. These are called "headless" applications in the Eclipse community, and you can find many tutorials for making one (here's one).
Requiring an IWorkspace shouldn't be a problem. You can e.g. create a workspace and a project in a temporary folder, and copy the code to be analyzed there.
If, for some reason, you really want to use just CDT's parser in an application that doesn't include the Eclipse Platform, you can probably copy the parser code from CDT, and replace any dependencies it has on the Eclipse Platform with your own implementations. However, this is likely to be a more labour-intensive approach, and I wouldn't recommend it.
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.
I'm creating a Java project which includes a few libraries written by myself. However these libraries are not finished and sometimes require some edits. Because I'm working by myself, I find this more efficient than finishing all libraries perfectly before using them in my project.
My question is: is it possible to automatically rebuild a modified library when building the project which uses it?
Subquestion: what is the optimal configuration for my purposes? Should I export libraries as jar and copy them into the final project or should I configure buildpaths of my project to retrieve them in their respective folders?
Subsubquestion: is it correct to use .jar libraries in the same way that one uses dynamic libraries in c++?
If you have Eclipse set to "build automatically", it'll take care of rebuilding the library projects whenever you make changes, as you go along. You should set your client program to depend on either the Eclipse projects (if doing everything inside Eclipse) or the Maven artifacts (if using m2e). I strongly prefer using Maven for all my Java builds, but it might be overkill for something small. Whatever you do, don't manually export and reimport the libraries.
All libraries in Java are dynamic, and a C++ .so or .dll is the basic equivalent.
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.
We have a fairly large C/C++ project using scons for the building. I'd like to go at an attempt to build this through Eclipse-CDT. Anyone have any experience with this and can tell me the steps to set up scons as a builder. (NOT using the SConsBuilder plugin, it will not work with the Eclipse-CDT from Fedora-11).
You can use a Makefile that simply delegates the important targets to scons
.PHONY: all clean install
default: all
all:
scons
clean:
scons -c
install:
scons install
Then it is possible to use "Standard Make C Project" out of the box.
One of our students implemented a new SCons integration for Eclipse CDT that works bi-directional, i.e., it can import SCons files and populate Eclipse CDT projects with the corresponding settings and it can generate SCons files from Eclipse project settings. In addition it provides an interactive SCons mode that speeds up incremental building of larger SCons projects significantly. It will be released to the public for free soon, see http://sconsolidator.com
I've tried Waf in Eclipse CDT before now, SCons would be really similar. The solution was to create an empty Makefile project, then simply change "make" to "scons" in the options. On Windows that would probably need the scons.bat file in your path. That is not much better than creating a dummy Makefile that has an all:\n\tscons type pattern in it, but is the least work.
The SConsBuilder plugin is not a good idea. It has a whole bunch of hard coded python code in there that it spits out to a SConstruct. It hasn't been updated in ages and a lot of code is probably deprecated in SCons by now. I think a better approach is to do what SCons does for Visual Studio, or what CMake does for Eclipse CDT. That means generating a .cproject file on the fly based on your build configuration.
I wrote an Eclipse project generator for Waf at one point, which walks the build nodes gathering source files and spits out a .project and .cproject file. Similar to how CMake does it, but Waf's default behaviour of creating a variant directory means you don't have to deal with out-of-source build issues. This has since been added as an extra in waf itself. It uses only part of the Waf API so it would be possible to convert it to SCons with some small-ish amount of work. In other words, there's nothing much out there. The .cproject format is not really documented anywhere and is really ugly compared to the Java version.
I didn't get on too well with CDT though - it is a long way behind the Java dev tools - and I still use Vim with :make, so it was all a bit academic in the end.
Just change builder settings, no plugins required. Choose external builder and set scons instead of make and set workdir to dir where SConstruct placed.
Now, you can use make targets view to create scons build commands and execute it like make commands. Error parsers with scons works fine by default, no additional configuration required.
http://sconsolidator.com/ Sconsolidator should work though.
Be VERY VERY careful about using Sconsolidator with an existing project!! It will blindly overwrite any existing SConstruct/SConscript files you have in the root directory of your project when you click the link to add a SCons nature to your project. (I'm trying to report this as a bug to the project, but being blocked at every turn so far.)