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.
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.
My book tell to add PHPUnit path to Global Include Path in Netbeans, but its use out of date PEAR way.
I installed PHPUnit using composer global require "phpunit/phpunit xxx". I run this command right in c:\
I got main PHPunit directory in: C:\Users\xxx\AppData\Roaming\Composer\vendor\phpunit
and two files in:
C:\Users\xxx\AppData\Roaming\Composer\vendor\bin
It depends, on how much code-completion support you want.
If you want the code-completion to work for all globally installed Composer packages,
then the path would be
C:\Users\xxx\AppData\Roaming\Composer\vendor
When you set this "Include Path" Netbeans will automatically scan the whole vendor folder and provide completion support for all classes of all packages. Scanning might take a while...
If you want completion support only for PHPUnit, then adding
C:\Users\xxx\AppData\Roaming\Composer\vendor\phpunit
is sufficent. Only the content of the phpunit folder will be scanned.
(I use the first approach, because PHPUnit has several other dependencies/packages (e.g. phpunit-selenium) and its nice to have support for these classes, too.)
The bin folder should contain a batch file: phpunit.bat.
This script might be used in the testing/ phpunit configuration as the "PHPUnit Script". When you invoke testing, this script will be used to start the Composer installed PHPUnit (, instead of the PEAR one).
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...
Trying to understand how EDE works by using it to generate Makefiles for
a project directory that contains several targets under a specific
hierarchy. I'm not having any luck, and the info pages don't seem to
answer my question.
My directory structure looks something like:
(The asterix (*) marks files containing main() functions)
research/
flow/
flow.cpp
flow.hpp
program.cpp *
samples/
sample1.yuv
utils/
yuvreader.cpp
yuvreader.hpp
tests/
yuvreader_test.cpp *
I want to create EDE project(s) with one or more subprojects; or maybe I
just want one or more targets...?
flow's program.cpp requires flow/ and utils/ sources, but yuvreader_test
only requires utils/ sources.
I did ede-new in the root directory, and all subdirectories. I also did ede-new-target in the root directory, but when adding source files in subdirectories, it does not recognize the target I created.
I would appreciate it if someone could point me to some more complicated
Project.ede files for something like I'm trying to do. You can guess
that I have more subdirectories containing class code files, some of
which have standalone programs that use that code; also I have more test
code under tests/. Any example files/command workflows would be
appreciated.
The EDE feature that will generate Makefile or Automakefiles has a few more constraints than either Make or Automake. For example, the files belonging to a target must be in the same directory as the project containing the target. In your example, you would probably have no projects in your root directory.
To bring multiple sources together into a single program, a simple mechanism is to have each subdirectory create an archive (.a) or a shared lib (.so) that is linked together in your program.
If that is too constraining, you can also write your own automake files, and EDE will read those directly, so you can have a more complex build procedure as needed.
The CEDET distribution uses EDE as its build process, so you could look at that as a complex example. It doesn't build C++ files though, so it may not be as helpful as you would like.
I'm developing a set of command line tools in Scala, using Apache Buildr as my build system. I'd like to include a wrapper script for each tool. Something like this:
#!/bin/sh
scala myclass $#
These scripts should be installed alongside my jar when I type buildr install. Is there a special directory Buildr recognizes for wrapper scripts like this? If not, how can I make Buildr install the scripts? I've tried putting the scripts in src/main/resources, but this packages them inside the jar, which is not what I want.
As commented, there are ways to make this happen by creating a separate packaging to encompass the scripts and the tool. Here is an example that bundles a jar and a set of scripts to run the jar with parameters.