I have a project written in C and I am using mercurial (I can use git too) for version control and GNU make for building. The project includes several empty directories used for build-time generated files, such as dependency makefiles and object files.
When I check out the project, however, empty directories are not created (they are ignored by the version control system) and the build fails.
The only remedy I have in mind is to add a mkdir -p directive in every single recipe in the 58 makefiles of the project (it is quite big). Apart from a lot of editing, mkdir -p is discouraged in the GNU make manual for being incompatible with other versions of make.
Is there any smarter way to overcome the problem?
Both git and Mercurial track files, not directories, so empty directories will not be stored.
The common trick is to just add an empty file to the directories you need, like:
touch output/.empty
And then add that to the repository.
You can have:
output/%: output/.empty
output/.empty:
$(MKDIR_P) output
touch output/.empty
in the makefile. Than all files in output will depend on creating the directory without modifying each rule separately.
The $(MKDIR_P) definition (mkdir -p for most systems or a special script where that does not work) can be provided by configuration script (e.g. autoconf using AC_PROG_MKDIR_P) or conditional setting in the makefile.
As you mention that you could use git as well, maybe that you would be interested by the fact that bazaar can track directories the same way it does for files. I don't know if it is an option for you, just saying.
Related
I have a C project I want to integrate with Lua.
This project has to be built on multiple platforms, so I want to build Lua in-tree with the rest of the C code, instead of depending on the system's Lua installation. Previously, we were using ax_lua macro to configure the system's Lua dependency, but I want to remove it and build Lua with the rest.
Unlike the other parts of the project, Lua already has a Makefile, and I don't want to convert this to Makefile.am just to get it converted back to Makefile.in then Makefile (unless, this is the only way.) Rather, I'd want something to the effect of running make inside the Lua folder and the rest of the build to proceed with the appropriate env vars (LUA_INCLUDE, LUA_FLAGS, LUA) set. To which files (configure.ac or Makefile.am) and what lines should I add to?
project/
lua-5.3.6/
Makefile
src/
a.c
b.c
configure.ac
Makefile.am
...
Rather, I'd want something to the effect of running make inside the
Lua folder and the rest of the build to proceed with the appropriate
env vars (LUA_INCLUDE, LUA_FLAGS, LUA) set. To which files
(configure.ac or Makefile.am) and what lines should I add to?
Unless you are willing to do it manually, it doesn't fit very well to try to build Lua before configuring the project. Moreover, even if you did build Lua manually in advance, unless you also installed it to the build system, it would be pretty optimistic to suppose that the macros from ax_lua would work as intended.
If instead you are content to build Lua via a recursive make during the overall project build, however, then the thing you're looking for is Automake's SUBDIRS variable. As its documentation describes, the subdirectories to be built do not have to be Automake-based. They just have to have makefiles (after configuration). The documentation also lists which targets the top-level makefile might try to build in the subdirectory, but it's not necessarily a showstopper if the subdirectory makefile does not support all of them. You would add this to your Makefile.am:
SUBDIRS = lua-5.3.6
The environment variables are a different question, whose answer depends in part on how the project depends on them. Probably you can just set the one you need (as make variables) in your Makefile.am. Since you are taking control of the Lua build, you can determine the needed values in advance. Everything in your Makefile.am is copied into the configured Makefile, so you don't need to do more to get those variables to the ultimate make.
For example, something along these lines might suffice:
LUA_INCLUDE = -I$(srcdir)/lua-5.3.6
LUA_LIB = lua-5.3.6/liblua-5.3.6.a
You might also consider dumping the variables in favor of just hardcoding the values, which, after all, will no longer vary.
I've installed mingw and msys by using mingw-get-setup.exe. I've also installed Autotools(autoconf, automake,m4,libtool) into C:\/opt/autotools.
When I run automake, the following error always occurs:
configure.ac:11: error: required file './ltmain.sh' not found
If I copy ltmain.sh from libtool’s installed tree, execution will finish normally.
How can I configuure automake to find ltmain.sh without copying?
In an autoconf/automake/libtool project you need to run:
libtoolize: this copies/links a few support scripts, including ltmain.sh (which is the main component of libtool).
aclocal: this looks up all m4 macros that your configure script will need, and make a local copy for easier access.
autoheader: optional, if you want to use config.h/AC_CONFIG_HEADERS, otherwise all the test result macros will be inlined when you call the compiler.
autoconf: to expand all the macros used by configure.ac into the configure script.
automake: to convert all the Makefile.am into Makefile.in templates. You probably want to invoke this with --add-missing so additional support scripts can be linked/copied to your project (such as compile, missing, depcomp, test-driver, etc).
Don't worry about running each tool. Just invoke autoreconf -i and it'll run the tools that are needed. Add -v if you want to see what tools is being executed. To avoid mistakes, just put a script like this at the root of your project:
#!/bin/bash -x
mkdir -p m4
exec autoreconf --install "$#"
Users that checkout/clone the project directly from the source repository will need to run this ./bootstrap script at least once. This is not needed if the user got a tarball distribution.
Automake can take fairly good care of itself; it'll re-invoke the above tools when needed, when you run make. But if you generate a broken Makefile, you'll need to invoke ./bootstrap and ./configure again to generate new Makefiles.
As DanielKO stated, ltmain.sh is created by libtoolize.
However, what if it doesn't?
The following requirements need to be met:
configure.ac must exist and contain at least one of:
AM_PROG_LIBTOOL,AC_PROG_LIBTOOL,LT_INIT
(see function func_require_seen_libtool in /usr/bin/libtoolize)
If configure.ac does not contain a AC_CONFIG_AUX_DIR, libtoolize will look for a file called 'install-sh' or 'install.sh' in ., .. and ../.. and if found use that as "auxdir" and install ltmain.sh there (see function func_require_aux_dir inside libtoolize).
In my case, I was working on an "example project" in a subdirectory of another project, and the example project did not have a AC_CONFIG_AUX_DIR in its configure.ac; therefore libtoolize found the root of the parent project and installed ltmain.sh there instead of in the example project's root.
I have a C program that was handed down to me by a developer who left. I am trying to figure out exactly what he had goign on and get the software re-arranged into something more logical so I can build it easier. I am using CMake to build, whereas he was using Make.
There is one src/ folder that had several source files in it, and out of those, about 4 had main() methods. The files with the main() methods are in files that are named more as if they are utilities, or tools, or whatever. This kind of strikes me as odd, because he also had a lib folder, with some other things in it that were built and looked more like libraries. Should I split out those main methods into "driver" source files, and make the methods that are also defined in those files to be other libraries? If I do this, I know how to make CMake go look for a library and build and link it to the driver for execution.
If it is acceptable to build those "library" source files where they are, in the src folder, should I just set CMake up to build everything in that folder all at once, or should I create a directory structure for at least some logical separation?
Just as an idea, here is the current directory structure
project
.../src
......file1.c
......file2.c <-has a main() as well as other methods
......file3.c
......file4.c <- has a main() as well as other methods
......file5.c
.../lib
....../lib1
........./file1.c <-references top level include folder files
........./file2.c
....../lib2
........./file1.c <-refs top level and local include files
........./file2.c
........./file2.h
.../scripts
.../include
.
.
.
Any advice on best practices for restructuring this build or configuring it in CMake is appreciated.
It's never too late for an answer, so I'd propose:
project
.../CMakeLists.txt
include_directories(include/)
add_subdirectory(lib/lib1)
add_subdirectory(lib/lib2)
add_subdirectory(src/)
.../lib/lib1/CMakeLists.txt
add_library(lib1 file1.c file2.c)
.../src/CMakeLists.txt
add_executable(test1 test1.c test2.c)
target_link_libraries(test1 lib1)
Why does it work: include_directories are derived in sub-directories, all targets (and thus libraries) from add_subdirectory are exported throughout the whole project.
I'm using QTCreator as a code editor for my C++ project, not using the real features of the qmake compilation process.
My project has several subdirectories, in all of which I ran qmake -project to create a duummy .pro file that simply lists the source and header files in the directory.
In my root folder, I simply created a "main.pro" file that includes all these "subdir/subdir.pro" files.
So it looks like this:
./
main.pro
subdir1/
/include
/src
subdir1.pro
subdir2/
/include
/src
subdir2.pro
Now my problem is, I use some files that have a special file extension (say, .ccp), which are actually some C code but are used in a different step of my compilation process.
They are naturally ignored by the qmake -project command and do not appear in my project.
I read here that I could use the qmake setting QMAKE_EXT_CPP to tell it to gather my files as a C-code file, but it doesn't seem to be working.
If I run qmake -query QMAKE_EXT_CPP, I get .cpp::.c::.ccp (which I set right before), but when running a new qmake, it doesn't take my .ccp files in account.
So, three questions:
Is it possible to make qmake take some special extensions as a C++ file, when building the .pro file?
If yes, is it correct to use the QMAKE_EXT_CPP setting?
If yes, what should be the syntax of the QMAKE_EXT_CPP setting? (mine inspired by this forum post, but it might be bogus).
You cannot change QMAKE_EXT_CPP with -project option. The list of cpp extensions used at this stage is hardcoded into qmake. However after initial creation of .pro file you can edit it to extend with support for other extensions:
in test.pro
QMAKE_EXT_CPP += .ccp
SOURCES += test.ccp
You have to add new files manually.
I have a large project where we have the following files:
A few 3rd party pre-compiled binaries
Our own in-house binaries
collection of Ruby scripts
A sizable Ruby on Rails project
This product will be installed on appliance hardware that my employer has already selected, using Ubuntu Linux (Lucid) as the target OS, with our goal of distributing the archive as a Debian package to ease installation and upgrades. Additionally, we have a number of ERB templates that we need to "fill-in" with appropriate values on a per-customer basis, so the use of the postinst script will be particularly handy for our purposes.
As a side note, the Debian packages will be stored on a server repository that we manage in-house.
At this stage, I have used dh_make to create the Debian directory and related files (e.g., rules, control, etc.), but the rules file that is generated seems like overkill for my purposes.
Based on this description, all I really need the "rules" file to do is simply copy files from a source directory (or within an archive) to the target directories shown below:
/opt/company_product/3rd_party_binaries/bin
/opt/company_product/3rd_party_binaries/etc
/opt/company_product/in_hourse_binaries/bin
/opt/company_product/in_hourse_binaries/etc
/opt/company_product/ruby
/opt/company_product/rails_project
/opt/company_product/etc
/opt/company_product/shared/logs
/opt/company_product/shared/tmp
/opt/company_product/shared/license
...and so on.
I've read the Debian Policy Manual and several How-To's which indicate that you should not alter the rules file to use mkdir to create directories and there is generally a dh_ app (e.g., dh_installdirs, et al) that can suit your needs for nearly any installation purposes. The man pages for these dh_ related apps are cursory at best, and I am an "example" kind of guy.
That said, I'm a little lost on what the best approach is to getting my rules file to install my various pre-compiled binaries and Ruby/Rails text files to the desired locations.
Here's my initial rules file. It's pretty much a standard boilerplate rules file that dh_make creates. My thinking is that I should comment out all sections except for the install and then find the appropriate command(s) to make directories, copy files, etc. within that section.
Any advice or suggestions are greatly appreciated.
#!/usr/bin/make -f
package = testapp
CC = gcc
CFLAGS = -g -Wall
ifeq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
CFLAGS += -O2
endif
#export DH_VERBOSE=1
clean:
dh_testdir
dh_clean
rm -f build
install: build
dh_clean
dh_installdirs
echo "Place the Install Script here"
cp $(CURDIR)/testapp-2.0.tar.gz $(CURDIR)/debian/$(package)/opt/testapp-2.0
echo "Finished copying folders"
build:
touch build
binary-indep: install
# There are no architecture-independent files to be uploaded
# generated by this package. If there were any they would be
# made here.
binary-arch: install
dh_testdir -a
dh_testroot -a
dh_installdocs -a
dh_installchangelogs -a
dh_strip -a
dh_compress -a
dh_fixperms -a
dh_installdeb -a
dh_shlibdeps -a
dh_gencontrol -a
dh_md5sums -a
dh_builddeb -a
binary: binary-indep binary-arch
.PHONY: binary binary-arch binary-indep clean checkroot
Although you've already got your own answer, I'll point out a couple of things.
You seem to be doing this in a very complicated manner. If you simply need to copy files into certain directories, write a debian/mypackagename.install with the following format:
path/to/file/relative/to/source/root path/to/install/relative/to/system/root
(do not prepend / before /usr, or /opt, or whatever your target directory is. Read man dh_install for more information)
Then your debian/rules can be:
#!/usr/bin/make -f
%:
dh $#
If you have some sort of makefile, etc in your source root, then append this to the above rules file:
override_dh_auto_build:
override_dh_auto_install:
Don't forget put 7 in debian/compat.
Also, you shouldn't install files into /opt/ or /usr/local/, etc. Those are meant for files not installed by Debian packages. Debian recommends installing in /usr/share/yourcompany/. As juzzlin points out below, the Ubuntu Software Center may have different requirements.
More specifically, your mypackage.install file should look like this:
src/bin/* usr/bin
src/etc/* etc/
You can install cdbs and change the rules file like this
#!/usr/bin/make -f
include /usr/share/cdbs/1/rules/debhelper.mk
binary-install/package_name::
mkdir debian/$(cdbs_curpkg)/destination_path
cp path_of_your_files debian/$(cdbs_curpkg)/destination_path