I have a problem.
I am currently working on a linux application (let's call it BigApp in this scenario). This application needs to be customizable via shared objects(so) and ini/text files.
The prerequisites for creating such shared objects are:
Generating a C file in a custom location (done from code)
an additional h file from the source repository of BigApp (done via makefile)
an executable shell script in the application bin folder (done), which sets up some parameters, calls the internal c file generator described above at number 1, and calls some kind of build script described below.
"the" build script which should compile the h file and the generated C file into a shared object.
The problem I have here is that once BigApp is installed, step 3 (compiling a new shared object) should be done by anyone with some basic linux-like skills. Also, the build script at number 4 should somehow use the same settings which were used when compiling and installing BigApp.
BigApp uses automake (makefile.am, configure.ac files for root and subfolders).
I assume I need a Makefile.am template to generate a particular makefile for the shared object when running configure on the BigApp, but I have no idea how to do this while avoiding it being run when I "make" the BigApp.
I could use any kind of suggestions or references to a tutorial.
Thank you!
EDIT: at the time, the build script for the shared library/object is a small shell script which simply calls gcc two times, but with no particular platform settings, and no relation to the BigApp makefiles.
It's been a while since you posted this question but what you should do is turn your current makefile for your shared libraries into a Makefile.in (or even write a Makefile.am using Automake) that gets completed by your configure script (created using Autoconf) for BigApp. You should study the GNU Build system manuals.
Related
Recently, I compiled gdb by using configure and make. To guarantee that the code was built into another directory (build), I executed the configure script from the build directory. (with ../binutils/configure)
Is this strategy (executing configure from within the wished build directory to specify the build directory) written down in some standard, a written convention or similar or does there not exist such a common practice?
It is e.g. documented here:
The GNU Build System distinguishes two trees: the source tree, and the
build tree. These are two directories that may be the same, or
different.
https://www.gnu.org/software/automake/manual/html_node/VPATH-Builds.html
E.g. the make distcheck makes use of this when doing its test build, and makes the source directory read-only so that any misconfigured build rule that creates files in the srcdir instead of builddir gets reported as an error during that check:
https://www.gnu.org/software/automake/manual/html_node/Checking-the-Distribution.html
So while autotools may not advertise this differentiation of source and build directories as strongly as Cmake does it actually has stronger support for it as Cmake is missing such a check feature.
I can't make a Stand alone exe file in VFP9. I have tried the following codes.
BUILD PROJECT XX FROM MAIN
BUILD EXE MAINEXE FROM XX
It will make an executable file. But its not a Stand alone. Any solution?
You cannot make an executable with VFP that would run without any runtime files. All you need is to add those few DLLs (listed below) to your executable's folder (if you don't have any other dependencies like FLLs, activex):
Vfp9r.dll
Vfp9t.dll
Vfp9Renu.dll
Note: If you think about it, that is the case with many languages out there. There are not so many languages where you can build native all-in-one executables (C, Go as examples).
I have read through most of OpenMesh's documentation, and am lost in how to run a simple program using OpenMesh. I followed the tutorial for making a basic cube and building the project: http://www.openmesh.org/media/Documentations/OpenMesh-6.2-Documentation/a00068.html but nowhere do they mention how to RUN the program. The tutorial says to put the file that makes the cube in a particular folder: http://www.openmesh.org/media/Documentations/OpenMesh-6.2-Documentation/a00066.html and I did this. It clearly compiled the code when I built it with cmake and make. After that I am lost.
Assuming you used the CMakeLists.txt as given in the page you linked as-is, the linker should create a file MyOwnProject within the directory where you executed cmake and then make. That's your executable. To run your program, execute that file, either by double-clicking it within a file manager (Explorer, if you are on Windows) or by typing ./MyOwnProject on a Linux command line.
How can I compile my Lua scripts into a single executable file, while also gaining the super fast performance benefits of LuaJIT?
Background:
My Lua scripts are for a web application I created (e.g. to host http://example.com)
My current technology stack is NGINX (web server), Lua/LuaJIT (language to retrieve dynamic content)
I have around 50+ .lua files that make up my web application (from Models/Views/Controllers)
FreeBSD 9 operating system
For simplicity sake in deployment, I'd like to compile down all of my .lua scripts that run my web application down to a single executable.
Is this possible and how?
It appears that Lua official comes with a library called SRLua
What are the negatives to compiling down my .lua to a single executable (e.g. would performance be worse, etc)?
Translate all of the Lua source code files to object files and put them in a static library:
for f in *.lua; do
luajit -b $f `basename $f .lua`.o
done
ar rcus libmyluafiles.a *.o
Then link the libmyluafiles.a library into your main program using -Wl,--whole-archive -lmyluafiles -Wl,--no-whole-archive -Wl,-E.
This line forces the linker to include all object files from the archive and to export all symbols.
For example, a file named foo.lua can now be loaded with local foo = require("foo") from within your application.
Details about the -b option can be found on Running LuaJIT.
For a web app that you are currently deploying as a nest of related .lua files, your easiest answer will be to condense them into a single file. This can often be done for simple cases with luac. However, for complex applications with a mix of modules you want something smarter.
I personally use Mathew Wild's utility squish to do something similar.
After running squish, you will have a single .lua file containing all the Lua source code bundled up conveniently. You could just deploy that single file.
If you need to also bundle any binary modules, or the Lua or LuaJIT interpreter, then you can easily use SRLua to bundle it with the Lua interpreter, or similar techniques to bundle it with LuaJIT.
I develop C/C++ using the Eclipse IDE. Eclipse also generates a makefile which I don't want to edit as it will simply be overwritten.
I want to use that makefile for nightly build within Hudson.
How do I pass #defines which are made in the project file of the IDE to the makefile ? (and why doesn't Eclipse already include them in the generated makefile?)
I actually had this figured out once, then accidentally overwrote it :-( But at least I know that it can be done...
If you are running make from the command line, use
make CPPFLAGS=-DFOO
which will add -DFOO to all compilations. See also CFLAGS, CXXFLAGS, LDFLAGS in the make manual.
You could write a small program to include the headers and write a makefile fragment which you include in the main makefile (requires GNU make).
This is a fairly ugly solution that requires a fair amount of hand hackery. More elegant would be to parse the project file and write the makefile fragment.
For GCC use -D define.
OP commented below that he wants to pass the define into make and have it pass it on to GCC.
Make does not allow this. Typically you just add another make rule to add defines. For instance 'make release' vs 'make debug'. As the makefile creator you make the two rules and have the defines right in the make file. Now if Eclipse is not putting the defines into the makefile for you, I would say Eclipse is broken.
If you're using autotools another options is to have 2 directories 'bin/debug' and 'bin/release'.
# Simple bootstrap script.
# Remove previously generated filed and call autoreconf.
# At the end configure 2 separate builds.
echo "Setting up Debug configuration: bin/debug"
../../configure CXXFLAGS="-g3 -O0 -DDEBUG=1"
echo "Setting up Release configuration: bin/release"
cd bin/release/
../../configure CXXFLAGS="-O2"
Setup Eclipse. Open the project's properties (Project->Properties->C/C++ Build->Builder Settings) and set the Build Location->Build Directory to
${workspace_loc:/helloworld/bin/debug}
Replacing 'helloworld' with your project's directory relative to the workspace (or you can supply an absolute path ${/abs/path/debug}). Do the same thing with the Release config, replacing "/debug" with "release" at the end of the path.
This method seems like a waste of disk space, but a valid alternative to achieve completely separate builds.