Does G-WAN support precompiled header?
For example if I have really big test.h file in the /csp folder, and then I compile it using:
$ g++ test.h
$ ls test.h*
test.h test.h.gch
Would G-WAN use the test.h.gch file when this file is included in a C++ servlet?
Would G-WAN use this test.h.gch precompiled file when this header is used by a C++ servlet?
First, doing it manually will work if g++ is looking for precompiled headers in their source code directory (they might instead be treated as temporary files created by g++ in a temporary directory).
Second, I am not sure that precompiled files are used by G-WAN because the answer depends on the persistence of g++ temporary files and the ability for consecutive compilations to lookup these files - a thing that we have never traced (we do not use C++ for our developments).
You can check this easily by compiling twice the same servlet and measuring the time. If the second compilation (after the servlet was modified) is faster than the first one then pre-compiled headers are used.
Procompiled headers speeds-up the compilation of C++ project (C++ is much slower to compile than plain C because (a) it is immensely more complex and (b) overloading allows the language syntax to hide completely different semantics... which level of complexity is decided by the C++ programmer).
Related
I have a specific question which serves as context for a more general question.
There is a scientific package called LAMMPS, and it is usually used as an executable. However, it supports use as a "library". To try to do things right, I put it in /usr/local/lib/lammps. It contains a lammps/src/ directory, which has around 40 source files. Using the instructions provided, I compiled lammps as a .so file in lammps/src/liblammps_serial.so.
I also have separate code in "~/code/ljtube/". This uses cmake to try to find the library. Thus, I wrote a FindLAMMPS.txt so that I could use
FIND_PACKAGE (lammps)
in my CMakeLists. I modified the libtool config file to search in /usr/local/ successfully. I found that it searches in /usr/local/lib/ for a .so file and in /usr/local/include/ for a .h file. So I made a dynamic link to the .so file in /usr/local/lib/, and I copied the .h file from the lammps/src/ to /usr/local/include/.
CMake can now find those two files, but it cannot link to anything else in lammps/src/. It seems absurd to need to make a separate FIND_PACKAGE for each of the .h's I want to include (group.h, fix.h, force.h, pair.h, etc.). It also seems ridiculous to dump the whole package of .h files into the /usr/local/include/ directory. I will be using this code both locally and on a cluster, and possibly distributing it to other group members.
How can I make CMake find what I want to find without hard coding in the location of /usr/local/lib/lammps/src/? Phrased more generically, how should I manage large packages like these to make them easy to link to in the code I write, even if the original developer did not use the best conventions?
(As a side note, I am using a shared library because it seems like the right choice, but I'm not especially married to it. Should I be using a static library? Is there a way for CMake to find an already-compiled library relative to the current source directory, and might that be a better way to implement this? I know that I will be using LAMMPS in multiple projects, so having a local shared copy superficially seems to make the most sense.)
Normally a find_package call yields a variable specifying the path to the "includes" folder of the package. This would then be added in the caller's CMakeLists.txt via include_directories.
For example, to use find_package for boost, you could do:
find_package(Boost) # sets ${Boost_INCLUDE_DIRS} and ${Boost_LIBRARIES}
if(Boost_FOUND)
include_directories(${Boost_INCLUDE_DIRS})
add_executable(foo foo.cc)
target_link_libraries(foo ${Boost_LIBRARIES})
endif()
Regarding your side note, you could use find_library and/or find_path to find the library and its headers given a known location.
Both these commands can be invoked in such a way as to avoid searching in common locations, e.g. by setting PATHS to the known location and using NO_DEFAULT_PATH in the find commands.
Another alternative is for your projects to make use of the ExternalProject_Add function which is described in more detail in this article. From this article:
The ExternalProject_Add function makes it possible to say “download this project from the internet, run its configure step, build it and install it”
A downside to this approach is that each of your projects would end up with its own copy of the third party sources and lib.
When it comes to using the terminal to build libraries manually and such I unfortunately do not have much experience and I'm stuck a bit here.
I've downloaded a library for objective-c which came with makefiles and such.
I can see that the folder also contains an executable file called "libtool", I did some searching and I suppose this is the program I have to use to build the neccessary .a files? Unfortunately I couldn't really find any useful article for this that seemed to work.
The folder for the library contains some .sh files, .pc files and also some .la files, but I'm a bit unsure of which ones I have to use as input to the libtool program to compile them into a .a file.
So my question is what files do you have to input into libtool to compile them into the necessary .a file? And what commands do you use exactly to accomplish this?
Thank you all for your time :)
First a little introduction to static libraries:
Static libraries in Unix environments (like Mac OSX, and Linux too) are actually just an archive of object files created by the ar command line program.
That is what the .a extension stands for: Archive.
To create a static library with some object files you can use the command like this:
ar crv libmy_library.a objectfile1.o objectfile2.o
As for your actual question, libtool should be called automatically from the makefile, creating the library, which is the file ending in .la. However, this is not the real library, the real library is in a hidden directory. You can find it by doing e.g.
find . -name '*.a'
But like I said, the makefile should already take care of everything, including installing the correct library in the correct place when you do e.g. make install.
For information about libtool, see this site.
I have a Fortran program that uses modules, i.e. it creates .mod-files during compilation.
I also wrote a Makefile that uses all the .f90-files from src/ puts all created .o-files in obj/ and the binary in the current folder, and everything works fine.
I now recompile my program in different folders for different calculations (say calc1/), i.e. I copy the Makefile into calc1/, type make all in calc1/ and all it does is the linking, because the object-files already exist. However, if the program includes any modules the compiler needs the corresponding .mod-files to be present in calc1/. Until now, I recompiled everything (make clean all), but with the program growing this takes too much time!
A possible solution I came up with is to have one specific folder for the binaries (bin/). But this is not a viable option because I have jobs in the queue, which obviously need a stable binary, while I also try new features in the meantime.
So, I'm looking for a solution that somehow treats the .mod-files similar to .o-files, e.g. places them in obj/.
I would expect that (most?) compilers would specify an option to change the module file path. with gfortran, the option is -J or -M (from the man page):
-Jdir
-Mdir
This option specifies where to put .mod files for compiled modules. It is also
added to the list of directories to searched by an "USE" statement.
The default is the current directory.
-M is deprecated to avoid conflicts with existing GCC options.
I think that most compilers look for .mod files in directories included with -I
EDIT
As of gfortran 4.6, -M is no longer supported. Use -J
based on one of my configure scripts, the flag is -module for ifort and pgf90 although I almost never use those compilers these days so somebody else should confirm that ...
Is there an Objective-C syntax checker?
I have tried gcc -fsyntax-only but it is not really 'syntax only'. It still produces errors if run on an individual implementation file which has references to external frameworks.
I am looking for something that can perform a syntax check on individual header or implementation files without attempting to link or produce object files.
Can gcc do this with additional flags I am unaware of, or is there another tool up to this task?
I want to do this from the command-line. Can xcodebuild do this for an individual file? Running xcodebuild for the entire project to check the syntax of one file is a bit much.
There's no way for it to check the syntax without it knowing about the header files for the frameworks you are using. You need to use the -framework flag to include the relevant header files.
You could try using clang -fsyntax-only instead, especially if you're using 10.6/Xcode 3.2. Clang/LLVM has much better separation between the parser and the other parts of the compiler chain. You can find clang in /Developer/usr/bin.
So after trawling through the gcc man page I discovered the -F flag which lets you add a framework directory to the list of directories gcc searches for header files.
This solves my issue.
Use it like this: gcc -fsyntax-only -ObjC -F/Path/To/A/Framework -F/Path/To/Another/Framework File.m
You can compile a single file in Xcode[1] using Build->Compile (cmd-K) which is effectively a syntax check (there's no linking step).
[1] I assume you're using Xcode, as there's little point in using Objective-C without OS X (really the Cocoa frameworks).
I'm wondering how i can make a portable build system (step-by-step), i currently use cmake because it was easy to set up in the first place, with only one arch target, but now that i have to package the library I'm developing I'm wondering how is the best way to make it portable for arch I'm testing.
I know I need a config.h to define things depending on the arch but I don't know how automatic this can be.
Any other way to have a build system are warmly welcome!
You can just use CMake, it's pretty straightforward.
You need these things:
First, means to find out the configuration specifics. For example, if you know that some function is named differently on some platform, you can use TRY_COMPILE to discover that:
TRY_COMPILE(HAVE_ALTERNATIVE_FUNC
${CMAKE_BINARY_DIR}
${CMAKE_SOURCE_DIR}/alternative_function_test.cpp
CMAKE_FLAGS -DINCLUDE_DIRECTORIES=xxx
)
where alternative_function_test.cpp is a file in your source directory that compiles only with the alternative definition.
This will define variable HAVE_ALTERNATIVE_FUNC if the compile succeeds.
Second, you need to make this definition affect your sources. Either you can add it to compile flags
IF(HAVE_TR1_RANDOM)
ADD_DEFINITIONS(-DHAVE_TR1_RANDOM)
ENDIF(HAVE_TR1_RANDOM)
or you can make a config.h file. Create config.h.in with the following line
#cmakedefine HAVE_ALTERNATIVE_FUNCS
and create a config.h file by this line in CMakeLists.txt (see CONFIGURE_FILE)
CONFIGURE_FILE(config.h.in config.h #ONLY)
the #cmakedefine will be translated to #define or #undef depending on the CMake variable.
BTW, for testing edianness, see this mail
I have been using the GNU autoconf/automake toolchain which has worked well for me so far. I am only really focussed on Linux/x86 (and 64bit) and the Mac, which is important if you are building on a PowerPC, due to endian issues.
With autoconf you can check the host platform with the macro:
AC_CANONICAL_HOST
And check the endianness using:
AC_C_BIGENDIAN
Autoconf will then add definitions to config.h which you can use in your code.
I am not certain (have never tried) how well the GNU autotools work on Windows, so if Windows is one of your targets then you may be better off finding similar functionality with your existing cmake build system.
For a good primer on the autotools, have a look here:
http://www.freesoftwaremagazine.com/books/autotools_a_guide_to_autoconf_automake_libtool