I have multiple source codes which I have to cross-build and use together as one huge project. The building process of each source code is the same './configure-make-make install' commands with added parameters for cross compilation. So far I have been managing this by typing a really long configure command "./configure CC=....." in text editor and then copy pasting that on to terminal and running it. Then repeating the process for another source code. Taking care of multiple include paths, library paths, pkg-config paths etc. the process turns out to be very messy, error-prone and cumbersome. I have already used eclipse ide and have found no option for configuring the "./configure .." command to my need. Is there any elegant way to handle this problem? I would like a solution which will require me to write minimal amount of script/instruction.
Is there any elegant way to handle this problem?
If you want to automatize the configuration and compilation of several sub-projects which are actually one project, I suggest you to use the GNU/Autotools canonical way to deal with it with is Nested Autotools project
In that way you can do a project which contains all the other projects in the following fashion:
./UmbrellaProject
subproject1/
subproject2/
...
Makefile.am
Inside the parent project Makefile.am you will have a line at the beginning such as:
SUBDIRS = subproject1 subproject2
More information at the GNU Automake docs
Related
I'm looking for a one file c++ build system for a simple c++ project on linux. The project has src/ and include/ directories. And I need a debug and a release build.
I can do this in one makefile but it's not straight forward and lacks readability.
I tried doing this with CMake, but it's not simple enough. It involves out of source builds and multiple CMakeLists. I guess I could live with the multiple CMakeLists, but I don't like the out of source builds.
Another thing I want is to be able to have easy one liners for debug and release version. For instance on makefile, I use, make debug and make release.
Is there a simpler one file solution that is readable?
My wishlist would also include support for git, but this probably requires its own question. By this I mean that it can combine multiple git/shell commands to simplify things. For instance, let us say you have a version in the CMakeList.txt and you want to both increment the version, push to git and tag the code all with "make release."
I looked at a few build systems and I ended up using CMake. It's not the solution I wanted, but I gave up and settled.
There a variety build systems you could use. Here is a couple:
SCONS
Gradle
I'd like to create a Makefile for a moderately sized C++ project (~110 .cpp and .h files) that was created in Xcode. I don't own a mac, so I can't just go into xcode and export a Makefile.
From my understanding of using Makefiles for simpler projects, I could go through and create a target in my Makefile for each .cpp file, including its prerequisites... but that would require manually looking through each file and sorting out what its dependencies are.
It's my understanding that autoconf is a good tool for this sort of problem, but I haven't been able to figure out how to set it up and I'm not even sure that it's the right tool for the job. So before I go even further down this rabbit hole --
What is the best way to create a Makefile for an existing project without one?
It is rather subjective as to the best tool. Perhaps look at SCONS or gradle to compare for your particular needs.
I think Pbxbuild may help you.
Pbxbuild (not to be confused with the OS X tool of the same name) is used to take Xcode project files and build the code. It does this by creating GNUmakefiles, and using Make to build those.
Any build system (generator) will require some learning on your part. I would suggest using CMake, if you do not mind that CMake will be required wherever anybody tries to build your source. Otherwise I would suggest using the Autoconf/Automake/Libtool combo.
I'm new to scons and trying to port over an existing visual studio solution (.sln) which internally references many VS project files (.vcxproj). The are multiple outputs, including a variety of libraries, and different executables.
From a conceptual point of view I'm unsure if I'm going down the right path and would appreciate any advice on how to do it better.
Here is my setup:
I have a top level SConstruct file at the root of the code depot. Additionally I have one SConscript file for each of my old VS project files. The SConstruct file calls the SConscript function once for each of these SConscript files, in which it specifies the source directory and where the outputs should go as parameters.
Additionally the SConstruct file creates and passes to each SConstruct file an array of scons environment instances. For example, there is one for compiling libraries, one for compiling executables, one for debug config, one for release, etc. and each SConscript file then chooses the one it wants, based on what it's trying to accomplish.
There are a couple things which I was wondering about:
1) Is there a better approach than creating multiple different environments, one for each configuration variation? Is that the expected usage pattern?
2) In visual studio, I could right click on a specific project and select build to only build that project and the projects it depends on, ignoring the rest of the dependency graph in the sln. With scons, is it true that it'll recompute the entire dependency graph every time I trigger a build of a specific library, even though in theory it would only need to compute a little portion of the entire dependency graph.
Thanks for any advice.
Mark
Your approach to having a SConstruct call several subsidiary SConscript files is indeed a good way to organize your projects, and is called a Hierarchical SCons build.
Regarding your questions, here are some things to consider:
Several different environments: Unless you have different compilers or compiler flags per builder or target (library, executable, etc) I would say that the approach you are using is a bit overkill. You could most likely achieve the same with just one environment. If you do need additional flags per sub-directory/builder, then you could consider passing the "main" environment to the subdirs, and in the respective SConscript's, clone the env and add/append what you need as mentioned here. This way the entire solution will be more modular by avoiding repetition and keeping everything common in one central place.
Building certain projects/targets: You can do the same with SCons by selecting the target on the command line, like this $ scons yourTarget. You can make the target names more manageable using the env.Alias() function. SCons does indeed analyze everything before building, but depending on the size of the project, it shouldnt be a problem, its still quite fast. If build performance does become an issue, here are some pointers for improving the performance.
Here are a few extra good things to know:
The SCons documentation is not bad WRT to other open-source tools. At the bottom of that doc page, there are several appendices with lots of extra information. The SCons man page is quite complete too.
Paths can be confusing in SCons if you're not Using the '#' as mentioned here
If you need to deal with MSVS projects, you can use the MSVSProject() and MSVSSolution() builers as mentioned here.
I am wondering how I should manage a growing C++ project. Now, I am developing a project with Netbeans and it's dirty work generating makefiles. The project has become too big and I have decided to split it up into a few parts. What is the best way of doing this?
I am trying to use Scons as my build system. I have had some success with it, but should I edit the build scripts every time I append or delete files. It's too dull.
So I need your advice.
P.S. By the way, how does a large project like google chrome do this? Does everybody use some kind of IDE to build scripts generated only for software distribution?
I also use Netbeans for C++ and compile with SCons. I use the jVi Netbeans plugin which really works well.
For some reason the Netbeans Python plugin is no longer official, which I dont understand at all. You can still get it though, and it really makes editing the SCons build scripts a nice experience. Even though Netbeans doesnt have a SCons plugin (yet?) you can still configure its build command to execute SCons.
As for maintaining the SCons scripts automatically by the IDE, I dont do that either, I do that by hand. But its not like I have to deal with this on a daily basis, so I dont see that its that important, especially considering how easy to read the scripts are.
Here's the build script in SCons that does the same as mentioned previously for CMake:
env = Environment()
env.EnsurePythonVersion(2, 5)
env.EnsureSConsVersion(2, 1)
libTarget = env.SharedLibrary(target = 'foo', source = ['a.cpp', 'b.cpp', 'c.pp'])
env.Program(target = 'bar', source = ['bar.cpp', libTarget])
The SCons Glob() function is a nice option, but I tend to shy away from automatically building all the files in a directory. The same goes for listing sub-directories to be built. Ive been burned enough times by this, and prefer explicitly specifying the file/dirs to be built.
In case you hear those rumors that SCons is slower than other alternatives, the SCons GoFastButton has some pointers that can help out.
Most large projects stick with a build system that automatically handles all the messy details for them. I'm a huge fan of CMake (which is what KDE uses for all their components) but scons is another popular choice. My editor (KDevelop) supposedly handles CMake projects itself, but I still edit the build scripts myself because it's not that hard.
I'd recommend learning one tool really well and sticking with it (plenty of documentation is available for any tool you'll be interested in). Be sure you also look into version control if you haven't already (I have a soft spot for git, but Mercurial and Subversion are also very popular choices).
A simple CMake example:
project("My Awesome Project" CXX)
cmake_minimum_required(VERSION 2.8)
add_library(foo SHARED a.cpp b.cpp c.cpp) #we'll build an so file
add_executable(bar bar.cpp)
target_link_libraries(bar foo) #link bar to foo
This is obviously a trivial case, but it's very easy to manage and expand as needed.
I am trying to use Scons as build system. I have some success with it, but I should edit
build scripts every time I append or delete file. It's too dull.
Depending on how your files are organized, you can use, for example, Scon's Glob() function to get source files as a list without having to list all files individually. For example, to build all c++ source files into an executable, you can do:
Program('program', Glob('*.cpp'))
You can do the same in CMake using its commands.
And, if you're using SCons, since it's Python you can write arbitrary Python code to make your source file lists.
You can also organize files into multiple folders and have subsidiary SCons (or CMakeList.txt) build files that the master build script can call.
What is a makefile and how do I use it?
A make file describes the compilation process. It describes which flags, compiler tools, linkers, etc. to use with which source code files and objects
More info
http://www.sis.pitt.edu/~mbsclass/tutorial/advanced/makefile/
The main purpose of a Makefile is to store every you need to build your project in one place. It contains the instructions for compiling your code, linking your compiled code, packaging the executables, extracting third party tools, and many other useful things. Pretty much any command you entire at the command line can be used in a makefile.
The advantage to using a makefile, when done correctly at least, is that anyone can easily build your entire project. It's as easy as typing make
An example of a Makefile for a windows project http://www.opussoftware.com/tutorial/TutMakefile.htm