Is there any IDE that exports Kconfig files to automatically add include and source folders, as well as setting the actual symbols that are defined there?
I mean, it's next to impossible to have a complete Eclipse environment for Linux Kernel development. Right now I basically have a "Makefile Project" with chosen include and source folders and built in build, but my code is dependent on symbols defined in kernel build.
EDIT
I just realized that kernel build generates a include/generated/autoconf.h, which is a great help in this and probably enough for most of the developers
There's a KDevelop plugin called kdev-kernel: https://github.com/Gnurou/kdev-kernel . It was an improvement over loading the kernel as a "generic makefile project" but isn't a complete solution.
It seemed to ignore some .config options, and it only works with specific versions of KDevelop. I'm not sure which ones, as I use Gentoo and usually compile a -9999 version of KDevelop (in Gentoo, -9999 indicates the head of some revision control branch... so the version depends on when I compiled).
In spite of the drawbacks, it might be worth trying or building upon; I find KDevelop's "intellisense" very useful.
Related
When I create a Fortran project by Eclipse,
it includes bin and src directories.
The automatically created Makefile has a rule that compiles test.f90 in src and its runnable is written in bin.
I am a pretty new to Fortran.
What if test.f90 is supposed to be just an object which is required to compile an executable file, where should the object file, say test.o, be put? and when test.f90 has a module inside, where should the module test.mod be output? mod at the same level as src and bin. or share, lib?
In that case, when I should separate all intermediate file in several directories, are there any template Makefile?
It depends on what kind of Fortran project you created. If you created a Makefile project, you have full control/responsibility for where files are located. It appears to create a src and bin directory but beyond that, it looks like you can put other files like *.mod and *.o wherever you want. I'm not sure what the convention is for Fortran Makefile projects.
I prefer to avoid using Fortran Makefile projects because I have zero desire to manually sort out dependencies and targets with Makefiles, but that's a personal preference; if you're familiar with make and need the fine control it gives you, this is a reasonable choice. Just starting out with a Fortran Makefile project seems really painful unless you already know make.
A simpler, though less obvious to choose "File | New | Fortran Project | Others" when creating a Fortran project, then select the compiler and what you want to build. An example is "Executable (Gnu Fortran on Linux/*nix)" for building an executable with gfortran on a unix/linux-like system. Build targets include executables, static libraries, and shared libraries, each using gfortran, ifort, and a few other compilers, on Windows, OSX, or linux/Unix.
The src and bin directories are not automatically created but Makefiles are managed by Eclipse. Eclipse will automatically create a directory like Debug or Debug_Intel64 and place executables, *.o, and *.mod files within it. If you make your own src directory, object files will be placed under Debug/src but the executables and module files will be under Debug. This directory name changes if you create a Release build configuration (Debug is the default).
By default, Eclipse puts all new source files in the project root but you can create Fortran source folders and organize your project however you want. The downside of automatic build management is that Eclipse is really only set up to build one thing, so if your project contains multiple executables (e.g. separate unit test, utilities, etc.) you need to manually build with make, CMake, etc.
Eclipse takes some getting used to, but integration with Mercurial is pretty good, and the Photran plugin (part of the Parallel Tools Project) helps with source templates, code analysis & Fortran refactoring tools, and a reasonably decent UI for configuring the compiler (at least for ifort on Linux). Plus it's cross-platform and works with a lot of other languages so it's far from the worst choice, especially if you're using Photran.
If you're not sold on Eclipse, I'd look at some less heavyweight options. Eclipse can be a pain some times and you might find a better IDE for what you're doing. OTOH, Eclipse works fine and the Photran plugin has some really nice features.
For fortran beginners the best IDE is codeblocks
download the binaries with Mingw fortran compiler.
As your requirement it puts all your .mod and .o files to obj folder and executables in bin folder and source files are just used from the directory where they are.
I have a question about local packages and gulp using them. The problem is, I have a packages.json in my working directory of my IDE with a lot of dependencies which also have dependencies. Now that wouldnt be much of a problem, but when I install them through npm, I get the directory node_modules.
The problem is that I have to build often but since the modules are getting installed in my local directory, my IDE starts to scan them and build the workspace. It hangs every time probably due to the complex dependencies. Apparently I need those packages locally because the gulpfile require('')s them.
I wonder if anyone else has stumbled upon this problem and what their strategy was for excluding the dependencies of their workspace. Eclipse (or in fact Zend Studio which I use, derived from it) doesn't seem to have its own exclude for it.
PS: I tried copying all to my global directory (where all packages are installed with the --global flag set) but there are that many dependencies within depedencies that the path becomes too long for Windows to handle (yeah I know, Windows). That didn't became a suitable solution either.
This sounds similar to big Node.js projects in Eclipse issue https://github.com/Nodeclipse/nodeclipse-1/issues/159
The solution would be disabling JSDT nature for there project (see Nodeclipse not recognizing generator functions answer)
See http://www.nodeclipse.org/history
I've been following the instructions shown on http://visualvm.java.net/build/build.html when attempting to build JVisualVM.
I checked out the trunk to my hard-drive, I've downloaded http://java.net/projects/visualvm/downloads/download/dev/nb73_visualvm_14012013.zip and extracted its contents to the visualvm/ directory, as asked:
To build the visualvm core tool you need the NetBeans 7.3 platform and profiler binaries available here. These binaries must be extracted into the trunk/visualvm directory. You can use ant run or ant build-zip to build or run VisualVM.
When executing ant run I got a:
compile:
[mkdir] Created dir: C:\Users\user\Desktop\jvisualvm\visualvm\applicationviews\build\classes
[nb-javac] Compiling 19 source files to C:\Users\user\Desktop\jvisualvm\visualvm\applicationviews\build\classes
[nb-javac] warning: [options] bootstrap class path not set in conjunction with -source 1.5
[nb-javac] C:\Users\user\Desktop\jvisualvm\visualvm\applicationviews\src\com\sun\tools\visualvm\application\views\threads\ThreadMXBeanDataManager.java:117: e
rror: cannot find symbol
[nb-javac] super(dummyLong, CommonConstants.SERVER_RUNNING, CommonConstants.SERVER_PROGRESS_INDETERMINATE);
[nb-javac] ^
[nb-javac] symbol: variable SERVER_RUNNING
[nb-javac] location: interface CommonConstants
[nb-javac] C:\Users\user\Desktop\jvisualvm\visualvm\applicationviews\src\com\sun\tools\visualvm\application\views\threads\ThreadMXBeanDataManager.java:117: e
rror: cannot find symbol
[nb-javac] super(dummyLong, CommonConstants.SERVER_RUNNING, CommonConstants.SERVER_PROGRESS_INDETERMINATE);
[nb-javac] ^
[nb-javac] symbol: variable SERVER_PROGRESS_INDETERMINATE
[nb-javac] location: interface CommonConstants
[nb-javac] Note: Some input files use unchecked or unsafe operations.
[nb-javac] Note: Recompile with -Xlint:unchecked for details.
[nb-javac] 2 errors
[nb-javac] 1 warning
I've even installed Netbeans 7.3 but that didn' seem to help a bit!
I'm quite new to these matters, am I missing something?
You mentioned that you are "quite new to these matters", so may I ask if there is a reason you want to build the trunk, specifically? Most of the time, the workflow when using SVN for source control includes tagging releases under /tags. The tagged releases have generally been tested and met a minimum testing criteria to be considered suitable for release, so you will probably have an easier time building one of the tags.
There is nothing wrong with building /trunk for yourself, but it should be considered an "unstable/work in progress" build, so you should expect to encounter problems.
As you may already know, there are pre-compiled binaries available for download on the VisualVM site. If there is no binary for your operating system listed, you can probably find it with your package manager (e.g. sudo apt-get install visualvm on Ubuntu).
That said, don't let me discourage you from trying, if you want to:
In this case, the compiler is telling you that it cannot find the symbols SERVER_RUNNING and SERVER_PROGRESS_INDETERMINATE in the CommonConstants class. These are referenced on line 117 of the ThreadMXBeanDataManager class. If you take a look at that class, you will see the import org.netbeans.lib.profiler.global.CommonConstants statement, which tells us that CommonConstants comes from NetBeans. If we examine the SVN commit history for the ThreadMXBeanDataManager class, we can see that the developer made the changes intending to make VisualVM compatible with NetBeans 7.3. So, there are a few possiblities:
The developer was wrong, and was actually compiling with some other version of NetBeans (possibly a pre-release, etc). If you find that this is the case, you should file a bug report (and a patch, if possible).
You are trying to compile against the wrong version of NetBeans.
Something is wrong with the classpath/build script.
Let's examine #2 and #3. We can take binary you linked to and find out which jar(s) the CommonConstants class lives in by using JFind or a similar utility (or by Googling, etc.):
We see that the class lives in two places, so the next thing to do is check both of the class files and make sure that they have the constants. Use an unzip utility (e.g. 7-zip) to expand the jar files and use a decompiler (I like JD-GUI) to verify that the class has the constants:
The version you linked to seems OK on my machine, so unfortunately now you have to investigate further. Are either or both of these jars on the classpath in the Ant script that does the compilation? Do you have a different version of the jar on your classpath via an environment variable? There are a lot of possibilities here, so you will have to do some sleuthing. If all of this seems like a lot of work, then I suggest you go with one of the pre-compiled binaries or switch to a tag build.
It looks like you are compiling it against NetBeans 7.2. Did you opened the VisualVM project in NetBeans before you tried to compile it? If so, please check which NetBeans Platform is set for top-level VisualVM project in NetBeans. You should compile VisualVM against NetBeans platform from nb73_visualvm_14012013.zip. To check that your installation is correct, try the following:
If you have VisualVM open in NetBeans, close NetBeans
find all trunk/visualvm/*/nbproject/private directories in the VisualVM source tree and delete private directory.
use ant run from command line
If that works, open NetBeans, register trunk/visualvm/netbeans as NetBeans Platform and set is as platform for VisualVM top-level project.
I think it is quite normal to have more than one binary in a project. However, with Eclipse CDT I don't know how to set up the IDE to get things done.
I know I can create several projects - one per binary. And I know I can set the dependencies per project. However, I cannot regard them as one project in Eclipse. If I'd like to share the code with a version control system (like svn), each developer has to import the projects separately.
What I miss is something like the Solution (sln file) in Visual Studio. Should I create a single project and create the make files by myself?
I haven't tried it out yet, but there is this 'project set' which can be ex- and imported. Is this the solution? Can this be put into version control?
My goal it to put everything under version control, not only subprojects. I cannot imagine that CDT makes only sense for single-binary applications.
How can I work properly?
I am quite sure CDT doesn't support sub-projects, which leaves you pretty much with:
one workspace per "set of projects"
one project per binary (like you mention in your question)
project dependencies (like you mention in your question)
In term of version control, that means:
submodules (Git),
subrepos (Mercurial) or
external (SVN)
for each project needing a shared library project.
In short, that means putting under version control various components (set of files), with one referencing specific version of others (that list of specific versions of other components is called a "configuration", based on a component-based approach development)
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.)