Alright, so I've been racking my mind on how to include a library, Derelict(2), in the eclipse plugin, DDT or Descent, and I can't for the life of me get it. I'm missing something BIG.
I've made sure everythings been placed and unpacked the right way:
- Installed DMD compiler
- Installed and Configured DDT to its default (druntime/import and phobos)
- YUM installed derelict2, causing the .di files to be available in the dmd folder
I've tried everything from manual downloads and makes with lib pragmas to altering the buildpath to include the derelict .di files. All have failed.
What in the world am I doing wrong?
You probably forgot to specify the library search path. So, say your libraries you want to use are in /home/duser/lib, then your DMD command line should contain -L-L/home/duser/lib to instruct DMD compiler where to look for those libraries. I do not know where in the DDT you specify library search paths... The same thing is with the third-party D sources, or D interface files - you need to specify the include search path as well (similar to C/C++ header files) with the -I flag...
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.
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.
In this question about compiling c code in a Module::Build module, it was suggested to use c_source to specify the location of the c/c++ source code.
This configuration option results in compiling the source to object files, and adding the directory to the linker's search path.
I would like to know if a similar configuration can be achieved, where all .c files are compiled to standalone executables, and installed next to the bin/ scripts.
You could check out the Alien:: set of modules, which do a superset of what you want I think. It looks like https://metacpan.org/pod/Alien::Base::Authoring is a good place to start.
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.
As I'm quite new to Java, I would like to know the proper procedure of installing new libraries (those that are no available in my linux dist repositories).
Where should I place them? and how to install them?
For instance, I downloaded openCsv (http://opencsv.sourceforge.net/), and I have no idea how to install it.
Java libraries don't really need to be 'installed' like other applications. All you need to do is put the jar file in a specific location, and add the jar file to your classpath. How you do that depends on the linux distro you are using. If you are making a web application in eclipse, you can drop the .jar file in the WebRoot/web-inf/lib folder, and it will be bundled in with your project.
Be sure that the path, which you place the libaries at, is set in the $CLASSPATH Environment Variable.
For Eclipse: Project -> Properties -> Java Build Path -> Add JARs...
It's up to you really - I use /opt/javalib, but you might consider a directory in /usr/local as well.
You can store them wherever you wish. You can store them within the JRE distribution directories, but I wouldn't recommend that.
Instead I would store them per-project (so you can have different versions for each project easily - some libraries have different names for each version, some don't) and adopt a standard such as a lib/ directory. That way you can have standard build scripts (Ant etc.) that can operate in the same way (if you're using Maven, then there's a standard place per-project - src/main/resources)
You could use Maven to manage any dependencies to those libraries.
Maven will automatically download all needed JAR files and put them in a local repository (the location is configurable).
This makes upgrading to new versions of various libraries very easy as you just declare the version you want and Maven does the rest.
Beware: Maven is something to get used to and the initial learning curve is steep.
The rewards come if you have everything set up properly and maven takes care of compiling, packaging, distribution, site creation, release management etc. etc. etc.