autotools

问题 The AC_ARG_VAR macro declares a variable precious which has certain cache-checking implications. Some configure macros declare certain variables precious, and I would like to undo that. For example, AC_PROG_CC will declare CFLAGS as precious, and I need to make it non-precious. Motivation Doing this would allow me to modify CFLAGS in a top-level configure and allow sub-package configures to execute without clashing with cached CFLAGS value. See this question for more background. 回答1: AC_DEFUN

问题 How to compile and link third party libraries with automake? My file structure is: program/ | +--src/ | | | +--Makefile.am | +--main.cpp | +--lib/ | | | +--Makefile.am | +--library.cpp | +--Makefile.am +--configure.ac +--README Contents of automake files are pretty generic: # src/Makefile.am bin_PROGRAMS = program program_SOURCES = main.cpp # Makefile.am SUBDIRS = src lib dist_doc_DATA = README # configure.ac AC_INIT([program], [1.0]) AM_INIT_AUTOMAKE([-Wall]) AC_PROG_CXX AC_CONFIG_HEADERS(

问题 In my program, I have a somewhat complicated build process. Currently, in one directory I use include in Makefile.am with a file, that does not exist but has to be build on its own. The reason is that this include file is quite long. Further in the real program it is not just only one file but several and the generation process for this file can change from time to time. The Makefile.am looks something like this noinst_LIBRARIES = libtest.a nodist_libtest_a_SOURCES = file.c CLEANFILES = file

问题 To see what I am trying to do see below: My question is how can I conditionally set AM_CPPFLAGS or my_lib_la_CPPFLAGS inside of my Makefile.am. Such that when configure is run the right CPPFLAGS are set? Currently I am doing something to the affect of: lib_xml_wrapper_la_CPPFLAGS = -I../../ UNAME_S = $(shell uname -s) UNAME_P = $(shell uname -p) ifeq ($(UNAME_S),Linux) lib_xml_wrapper_la_CPPFLAGS += -DLINUX ifeq ($(UNAME_P),x86_64) lib_xml_wrapper_la_CPPFLAGS += -D AMD64 endif ifeq ($(UNAME_P

问题 Let's say I have a feature "foo" that I'm implementing for several operating systems. There is a generic way to do it, but if the OS has native support for it then I want to use that. How do I conditionally compile only the right source files with autotools? Example: Let's say "foo" is "reboot the machine". On Linux I would use reboot(), and I would put that in reboot_reboot.c, where I define myreboot() do just call reboot() with the correct parameters. On all the BSDs I would use bsd_made_up

问题 I have the following Autotools code for installing a systemd service file, which must be installed outside of $prefix to a directory given by a pkg-config variable: (I know this is not proper, but I can't change the way systemd works.) configure.ac AC_ARG_WITH([systemdsystemunitdir], AS_HELP_STRING([--with-systemdsystemunitdir=DIR], [Directory for systemd service files]), [], [with_systemdsystemunitdir=$($PKG_CONFIG --variable=systemdsystemunitdir systemd)]) AC_SUBST([systemdsystemunitdir], [

问题 I'm trying to build libFLAC to use in a project of mine, however when it comes to linking, GCC ignores the library because it says it was not built for the current architecture (i386). When I compile the program in 64-bit, it links the library properly which means the library was compiled for x86_64 architecture. Unfortunately, my program wont work in 64-bit, so I need to compile libFLAC as i386. I've tried using ./configure --build=i386 however it didn't seem to change anything. So far, I've

问题 E.g., I want to add the options --enable-foo --enable-bar to a ./configure command. Many ./configure options can be set indirectly through BR2_ configs, but many software have so many options that it would be infeasible to have one BR2_ config for every possible ./configure option. Is there a general mechanism that works for all autotools packages? 回答1: I think there is no current general method as of 2017.02, since package/pkg-autotools.mk contains: # Configure package for target define $(2)

问题 E.g., I want to add the options --enable-foo --enable-bar to a ./configure command. Many ./configure options can be set indirectly through BR2_ configs, but many software have so many options that it would be infeasible to have one BR2_ config for every possible ./configure option. Is there a general mechanism that works for all autotools packages? 回答1: I think there is no current general method as of 2017.02, since package/pkg-autotools.mk contains: # Configure package for target define $(2)

问题 I have been looking about this subject for a while and I think I know all I need about "should I put my autotools generated files in my repo?". I agree with everyone who says that you should not and include just wat is needed to generate them. Althought I think this is the right approach for development purposes I write a framework which uses git for version control (in the develop branches) and uses the master branch to distribute the code. My question is, is there an easy way to include in