what does parameter 'move-if-change' stands for in AC_INIT()?
I've read the documentation of AC_INIT but it is mentioned nowhere.
And also read the manual page for 'autoconf' but no chance, it wasn't
described there.
The code that I'm reviewing is bellow.
AC_INIT(move-if-change)
AC_DISABLE_OPTION_CHECKING
:NOTE:
I could not make it to work on 2.69 it keep asking for version 2.64,
I'm trying to compile crossgcc for coreboot. And I delete the line AC_PREQ
line between them but it still keep asking for 2.64.
In the old version of Autoconf (up to 2.13), AC_INIT had only one calling syntax:
AC_INIT(filename)
where filename was the name of a file in the source directory. This file would be used by ./configure to make sure that the directory it thinks is the source directory is actually the source directory. Today this syntax is obsolete (and has been for over 10 years). You should move away from it.
A more modern setup would be:
AC_INIT([package-name], [version])
AC_CONFIG_SRCDIR([move-if-change])
Related
I maintain a commercial, binary package for debian, ubuntu, & etc. and have gotten complaints about "bad package quality" from the Ubuntu installer. The root cause of this appears to be that the package installs files in the /opt and /etc/opt directories which apparently throws lintian into a hissy fit. As I understand the purpose of these directories, they are meant to serve the needs of "Add-on" applications although I have yet to see any definition of what "add-on" is supposed to mean. I have attempted to create a lintian override file for my package in the /usr/share/lintian/overrides directory and, when I do so, I get the following report from Lintian:
N: Some overrides were ignored, since the tags were marked "non-overridable".
N: The following tags were "non-overridable" and had at least one override
N: - dir-or-file-in-opt
Is there any way around this apparent obstinacy?
If you're using debhelper to build your package, lintian overrides for the binary packages should go in the debian folder with the filename [package].lintian-overrides. This ensures the overrides make it into the proper directory on package installation. (For source packages, overrides go in the file debian/source/lintian-overrides.)
That said, short of not putting your files in /opt, I'm not sure there's a way to completely get rid of the dir-or-file-in-opt lintian complaint. Though, I'm not sure it's necessary since, to my knowledge, the ubuntu/aptdaemon lintian profile (which disables the dir-or-file-in-opt tag) is used in most of the situations in which lintian would be run automatically during/before package installation. That's probably not quite the answer you were hoping for, but I hope it's helpful nonetheless!
Sources:
Debian New Maintainers' Guide, section 5.14
Lintian User's Manual, section 2.4
Cendio ThinLinc bug #5232
I am trying to learn CMake. I have the Mastering CMake book and I'm trying to go through my first "easy" tutorial. Using CMake: Hello World Example
I made it through the first part alright, but when I tried to add the sub folders for the "Building a library" part of the tutorial I'm just not getting it. I followed the instructions all the way to the very end.
**We've seen an example of how to build a program. Now let's make a library as well. The library will be called "namer" and it will have a single function "getWorld" that returns the name of the nearest planet. We choose to put this library in a subdirectory called "namer" - it doesn't really matter where we put it, this is just an example.
I made it a subfolder in my HelloWorld project. Should I be making this a separate project?
**One way we can help CMake find the Namer package (which will be our namer library) is by writing a helper script called FindNamer.cmake. This is just another file written in the CMake language that pokes around in all the places our library might be hiding. Here is an example (put this in "hello/FindNamer.cmake"):
This is my FindNamer.cmake file:
find_path(Namer_INCLUDE_DIRS world.h /usr/include "$ENV{NAMER_ROOT}")
find_library(Namer_LIBRARIES namer /usr/lib "$ENV{NAMER_ROOT}")
set(Namer_FOUND TRUE)
if (NOT Namer_INCLUDE_DIRS)
set(Namer_FOUND FALSE)
endif (NOT Namer_INCLUDE_DIRS)
if (NOT Namer_LIBRARIES)
set(Namer_FOUND FALSE)
endif (NOT Namer_LIBRARIES)
**The important parts here are the "find_path" and "find_library" commands, which look for the header file world.h and the namer library.
I followed the next instructions and at the very end the tutorial includes this:
**If we try again, configuration will still fail since the search path we gave for "find_path" and "find_library" doesn't actually include the needed files. We could copy them, or have added a hard-coded directory to find_path and find_library pointing to where the files are on our hard drive - but better, in the CMake GUI on windows or by running "ccmake ." on Linux, we can just fill in the directories there.
At this point I am completely confused (Newbie!!!!). I don't have a NamerConfig.cmake or namer-config.cmake file and I don't know what the find_path and find_library is supposed to be pointing to.
Thank you in advance for your help,
Severely Confused :-(
I said I was a newbie. I guess I'm a little tired too! Yes, these must be in two separate projects.
Is there a kind of "include" directive in RPM spec? I couldn't find an answer by googling.
Motivation: I have a RPM spec template which the build process modifies with the version, revision and other build-specific data. This is done by sed currently. I think it would be cleaner if the spec would #include a build-specific definitions file, which would be generated by the build process, so I don't need to search and replace in the spec.
If there is no include, is there an idiomatic way to do this (quite common, I believe) task?
Sufficiently recent versions of rpmbuild certainly do support %include:
%include common.inc
Unfortunately, they aren't very smart about it -- there is no known set of directories, in which it will look for the requested files, for example. But it is there and variables are expanded, for example:
%include %{_topdir}/Common/common.inc
RPM does not support includes.
I have solved similar problems with either m4 macro processor or by just concatenating parts of spec (when the "include" was at the beginning).
If you only need to pass a few variables at build time, and not include several lines from another file, you can run
rpmbuild --define 'myvar SOMEVALUE' -bb myspec.spec
and you can use %myvar in the spec.
I faced this same issue recently. I wanted to define multiple sub-packages that were similar, but each varied just slightly (they were language-specific RPMs). I didn't want to repeat the same boiler-plate stuff for each sub-package.
Here's a generic version of what I did:
%define foo_spec() %{expand:%(cat '%{myloc}/main-foo.spec')}
%{foo_spec bar}
%{foo_spec baz}
%{foo_spec qux}
The use of %{expand} ensures that %(cat) is only executed a single time, when the macro is defined. The content of the main-foo.spec file is then three times, and each time %1 in the main-foo.spec file expands to each of bar, baz and qux, in turn, allowing me to treat it as a template. You could easily expand this to more than one parameter, if you have the need (I did not).
For the underlying issue, there maybe two additional solutions that are present in all rpm versions that I am aware of.
Subpackages
macro and rpmrc files.
Subpackages
Another alternative (and perhaps the "RPM way") is to use sub-packages. Maximum RPM also has information and examples of subpackages.
I think the question is trying to structure something like,
two spec files; say rpm_debug.spec and rpm_production.spec
both use %include common.spec
debug and production could also be client and server, etc. For the examples of redefining a variable, each subpackage can have it's own list of variables.
Limitations
The main advantage of subpackages is that only one build takes place; This may also be a disadvantage. The debug and production example may highlight this. That can be worked around using strip to create variants or compiling twice with different output; perhaps using VPATH with Gnu Make). Having to compile large packages and then only have simple variations, like with/without developer info, like headers, static libraries, etc. can make you appreciate this approach.
Macros and Rpmrc
Subpackages don't solve the problem of structural defines that you wish for an entire rootfs hierarchy, or larger collection of RPMs. We have rpmbuild --showrc for this. You can have a large amount of variables and macros defined by altering rpmrc and macros when you run rpm and rpmbuild. From the man page,
rpmrc Configuration
/usr/lib/rpm/rpmrc
/usr/lib/rpm/redhat/rpmrc
/etc/rpmrc
~/.rpmrc
Macro Configuration
/usr/lib/rpm/macros
/usr/lib/rpm/redhat/macros
/etc/rpm/macros
~/.rpmmacros
I think these two features can solve all the problems that %include can. However, %include is a familiar concept and was probably added to make rpm more full-featured and developer friendly.
Which version are you talking about? I currently have %include filename.txt in my spec file and it seems to work just like the C #include directive.
> rpmbuild --version
RPM version 4.8.1
You can include the *.inc files from the SOURCES directory (%_sourcedir):
Source1: common.inc
%include %{SOURCE1}
In this way they will go automatically into SRPMS.
I've used scripts (name your favorite) to take a template and create the spec file from that. Also, the %files tag can import a file that is created by another process, e.g. Python's bdist-rpm.
I am trying to build an application with OpenSync 0.4 (0.3.9 indeed) dependency.
In the project's configure.ac the opensync library is written as libopensync1. However, this doesn't build on my Gentoo system. Changing libopensync1 to libopensync does fix the issue for me.
I searched with Google and found that libopensync1 is used in some distributions, while libopensync in others. So how to resolve this issue in configure.ac?
Thanks.
The macro AC_SEARCH_LIBS does what you need. (There is much heated debate about whether or not pkg-config should ever be used. If you choose to rely on it, ptomato gives a reasonable approach.) Simply add this to your configure.ac:
AC_SEARCH_LIBS([osync_mapping_new],[opensync1 opensync],[],
[AC_MSG_ERROR([can't find opensync])])
This will first look for a library named opensync1; if
it doesn't find that, it will look for opensync.
The primary drawback of using pkg-config is that most projects that
rely on it do not actually check if the data provided by the .pc
file is reliable, so configure may succeed but a subsequent build
will fail. It is always possible for a user to set PKG_CONFIG=true
when running configure and completely eliminate all of the data
provided by any associated .pc files, setting LIBS, CFLAGS, etc by
hand the 'old-fashioned' way.
The primary drawback of not using pkg-config is that the user
has to set LIBS, CFLAGS, etc. the old-fashioned way. In practice,
this is pretty trivial, and all pkg-config has done is move the
data from a single CONFIG_SITE file to separately maintained
.pc files for each package.
If you do use PKG_MODULE_CHECK, follow it up with a call to
AC_CHECK_LIB or AC_SEARCH_LIBS to validate the data in whatever
.pc file was located by PKG_CHECK_MODULES
I'm assuming that the place at which this occurs inside your configure.ac is inside a PKG_CHECK_MODULES call.
Looking at the libopensync sources, it seems that libopensync1 is the newer name, and libopensync is the old name. So, we'll use pkg-config macros to look for the newer name unless it doesn't exist.
Put this in your configure.ac:
# Check if libopensync1 is known to pkg-config, and if not, look for libopensync instead
PKG_CHECK_EXISTS([libopensync1], [OPENSYNC=libopensync1], [OPENSYNC=libopensync])
Then later in your PKG_CHECK_MODULES call, replace libopensync1 with $OPENSYNC.
In this instance I'm using c with autoconf, but the question applies elsewhere.
I have a glade xml file that is needed at runtime, and I have to tell the application where it is. I'm using autoconf to define a variable in my code that points to the "specified prefix directory"/app-name/glade. But that only begins to work once the application is installed. What if I want to run the program before that point? Is there a standard way to determine what paths should be checked for application data?
Thanks
Thanks for the responses. To clarify, I don't need to know where the app data is installed (eg by searching in /usr,usr/local,etc etc), the configure script does that. The problem was more determining whether the app has been installed yet. I guess I'll just check in install location first, and if not then in "./src/foo.glade".
I dont think there's any standard way on how to locate such data.
I'd personally do it in a way that i'd have a list of paths and i'd locate if i can find the file from anyone of those and the list should containt the DATADIR+APPNAME defined from autoconf and CURRENTDIRECTORY+POSSIBLE_PREFIX where prefix might be some folder from your build root.
But in any case, dont forget to use those defines from autoconf for your data files, those make your software easier to package (like deb/rpm)
There is no prescription how this should be done in general, but Debian packagers usually installs the application data somewhere in /usr/share, /usr/lib, et cetera. They may also patch the software to make it read from appropriate locations. You can see the Debian policy for more information.
I can however say a few words how I do it. First, I don't expect to find the file in a single directory; I first create a list of directories that I iterate through in my wrapper around fopen(). This is the order in which I believe the file reading should be done:
current directory (obviously)
~/.program-name
$(datadir)/program-name
$(datadir) is a variable you can use in Makefile.am. Example:
AM_CPPFLAGS = $(ASSERT_FLAGS) $(DEBUG_FLAGS) $(SDLGFX_FLAGS) $(OPENGL_FLAGS) -DDESTDIRS=\"$(prefix):$(datadir)/:$(datadir)/program-name/\"
This of course depends on your output from configure and how your configure.ac looks like.
So, just make a wrapper that will iterate through the locations and get the data from those dirs. Something like a PATH variable, except you implement the iteration.
After writing this post, I noticed I need to clean up our implementation in this project, but it can serve as a nice start. Take a look at our Makefile.am for using $(datadir) and our util.cpp and util.h for a simple wrapper (yatc_fopen()). We also have yatc_find_file() in case some third-party library is doing the fopen()ing, such as SDL_image or libxml2.
If the program is installed globally:
/usr/share/app-name/glade.xml
If you want the program to work without being installed (i.e. just extract a tarball), put it in the program's directory.
I don't think there is a standard way of placing files. I build it into the program, and I don't limit it to one location.
It depends on how much customising of the config file is going to be required.
I start by constructing a list of default directories and work through them until I find an instance of glade.xml and stop looking, or not find it and exit with an error. Good candidates for the default list are /etc, /usr/share/app-name, /usr/local/etc.
If the file is designed to be customizable, before I look through the default directories, I have a list of user files and paths and work through them. If it doesn't find one of the user versions, then I look in the list of default directories. Good candidates for the user config files are ~/.glade.xml or ~/.app-name/glade.xml or ~/.app-name/.glade.xml.