标签: autotools

在我的 src 目录中，我有neoleo.iswigneoleo_wrap.c通过规则创建的接口文件：

neoleo_wrap.c : $(srcdir)/neoleo.i neoleo_swig.c neoleo_swig.h
        swig -tcl8 $(srcdir)/neoleo.i

当我输入make dist ; make distcheck它时输出：

swig -tcl8 ../../../src/neoleo.i
Unable to open file ../../../src/neoleo_wrap.c: Permission denied
make[2]: *** [Makefile:1313: neoleo_wrap.c] Error 1

我需要做什么来解决这个问题？

我的一些相关部分Makefile.am：

EXTRA_DIST = $(srcdir)/neoleo.i
BUILT_SOURCES = getdate.c parse.c parse.h posixtm.c posixtm.h neoleo_wrap.c
nodist_libneoleo_la_SOURCES = neoleo_wrap.c
neoleo_wrap.c : $(srcdir)/neoleo.i neoleo_swig.c neoleo_swig.h
        swig -tcl8 $(srcdir)/neoleo.i

完整Makefile.am可用在这里：

生成文件

我知道我可以使用AC_CHECK_DECL / AC_CHECK_DECLS来检查一组标头是否提供了指定标识符的声明，但是如何不仅检查宏是否已声明，而且还检查其扩展是否满足我的条件？具体来说，我想检查是否numa.h包含与此等效的宏定义...

#define LIBNUMA_API_VERSION 2

...包括特定值“2”。

更新： <numa.h>标头包含一个定义，例如#define LIBNUMA_API_VERSION 2声明其版本。使用此标头的 C 代码通常如下使用：

#if defined(LIBNUMA_API_VERSION) && LIBNUMA_API_VERSION >= 2
....
#endif

我想使用 确定 NUMA 标头版本autoconf，并定义一个宏来简洁地传达是否提供 NUMA 版本 2。IE：

if test "$have_numa_v2" = "yes" ; then
    AC_DEFINE(NUMA_VERSION_2, 1, [Determine whether NUMA v2 available)
fi

可以像这样使用：

#ifdef NUMA_VERSION_2
....
#endif

是否可以？我无法确定如何have_numa_v2在 Autoconf 文件中设置变量变量的值。

我有一个看起来像这样的存储库

configure.ac
GNUmakefile.in
src
 |--lib
 |--bin

其中src/lib包含要构建的共享库的源代码，src/bin包含多个二进制文件的源代码（其中一个由同一目录中的多个静态库组成）。

• 问题 1：某些二进制文件也需要与第三方库链接，但不是全部
• 问题 2：其中一个库在 Linux 和 FreeBSD 上的命名不同

我在这篇文章中看到，我可以通过使用 AC_SUBST 将找到的库的名称保存在自定义变量中来解决问题 1。但是，当使用像这样的循环宏时，如何保存第一个找到的库的名称（无论它是什么）AC_SEARCH_LIBS，即：

AC_SEARCH_LIBS([func], [lib_name_on_linux lib_name_on freebsd], [AC_SUBST([MYLIB], [????])])

一种解决方法是进行两次不同的调用AC_CHECK_LIB：

AC_CHECK_LIB([lib_name_on_linux], [func], [AC_SUBST([MYLIB], ["-llib_name_on_linux"])])
AC_CHECK_LIB([lib_name_on_freebsd], [func], [AC_SUBST([MYLIB], ["-llib_name_on_freebsd"])])

这会起作用，因为上面只有一个AC_CHECK_LIB会成功，但它很丑陋，如果我想打印错误（如果两者都没有找到），那么如果没有额外的代码，它就无法工作。这样做的正确方法是什么？

我写了一个依赖于libxml ++和curl的库,我很难AC_CHECK_LIB在我编写的另一个包中找到如何使用我的库.该config.log文件为新的包裹表示有未定义的引用curl_*和xmlpp::*.

我已经PKG_CHECK_MODULES在我的最新软件包中设置了libxml ++和curl,这些工作,但它们显然不适AC_CHECK_LIB用于我自己的库的调用.(在检查我自己的库之前,我检查了libxml ++和curl)

假设我要包含一个库：

#include <library.h>

但我不确定它是否已安装在系统中。通常的方法是使用自动工具之类的工具。C ++中有更简单的方法吗？例如，在python中，您可以处理异常。

我正在尝试从Windows 上的源代码构建shapelib。该库使用自动工具。我已经安装了带有适当软件包的 MinGW。当我跑

C:\MinGW\msys\1.0\bin\sh autogen.sh

它输出

autogen.sh: line 4: readlink: command not found
autogen.sh: line 4: dirname: command not found
**Error**: Directory `' does not look like the top-level package directory

我不希望 readlink 可以与 Windows 一起使用，所以我直接跳过了

C:\MinGW\msys\1.0\bin\sh configure

但是，这也会引发错误

configure: line 478: sed: command not found
configure: line 477: expr: command not found
configure: line 478: sed: command not found
configure: line 492: sed: command not found
: error: cannot create .lineno; rerun with a POSIX …

src/Makefile.am：

myproj_CXXFLAGS = -fopenmp -O3 -std=c++17 -g -I/home/software/miniconda3/include -I$(top_srcdir)/external
myproj_LDFLAGS = -L/home/software/miniconda3/lib -Wl,-rpath=/home/software/miniconda3/lib -fopenmp -lz -ligraph -pthread 
bin_PROGRAMS = myproj
myproj_SOURCES = gfa.cpp  graph.cpp myproj.cpp gfa.h  graph.h
bindir = $(top_srcdir)/bin

这很好地构建了目标文件，但是在构建目标时，它会尝试运行

g++ -fopenmp -O3 -std=c++17 -g -I/home/software/miniconda3/include -I../external -g -O2 -L/home/software/miniconda3/lib -Wl,-rpath=/home/software/miniconda3/lib -fopenmp -lz -ligraph -pthread   -o myproj myproj-gfa.o myproj-graph.o myproj-komb.o 

这个问题是目标文件在库文件之后，这会导致错误

/home/software/miniconda3/lib/libz.so: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status

我可以通过-lz -ligraph在最后添加标志来轻松解决这个问题，但是我怎样才能让 automakeLDFLAGS在目标文件之后而不是之前添加呢？

另一个Autotools问题...我正在研究Fedora 27，并且正在尝试构建libidn和 libidn2。我需要configure; make; make install实际工作。我需要它工作的机器只有Autoconf，Automake，Autopoint，Libtool和编译器工具。他们没有别的东西，就像这样<something>2html，<something>2pdf所以我无法构建文档。我也不能autoreconf 按照手册运行，因为那也坏了。

我不知道为什么这些工具会尝试构建文档，因为我使用禁用了它们--disable-gtk-doc --disable-gtk-doc-html --disable-gtk-doc-pdf。我曾尝试使用HELP2MAN=true和解决它MAKEINFO=true，但是Autotools找到了另一种破解方法：

gmake[2]: Entering directory '/home/Build-Scripts/libidn-1.33/doc'
echo '# This file is automatically generated.  DO NOT EDIT!          -*- makefile -*-' > Makefile.gdoc
echo >> Makefile.gdoc
echo 'gdoc_TEXINFOS =' >> Makefile.gdoc
echo 'gdoc_MANS =' >> Makefile.gdoc
echo >> Makefile.gdoc
for file in ../lib/idna.c ../lib/nfkc.c ../lib/pr29.c ../lib/punycode.c ../lib/stringprep.c ../lib/tld.c ../lib/toutf8.c ../lib/version.c ../lib/idn-free.c ../lib/strerror-idna.c ../lib/strerror-pr29.c ../lib/strerror-punycode.c ../lib/strerror-stringprep.c …