Automake 和同名文件

发布于 2024-07-21 13:31:32 字数 943 浏览 8 评论 0原文

我有一个 C++ autoconf 托管项目，我正在对其进行修改以在 FreeBSD 主机上进行编译。最初的系统是 Linux，所以我创建了一个 AM_CONDITIONAL 来区分我正在构建的主机，并将代码分离到系统特定的文件中。

configure.ac

AC_CANONICAL_HOST
AM_CONDITIONAL([IS_FREEBSD],false)
case $host in
        *free*)    
            AC_DEFINE([IS_FREEBSD],[1],[FreeBSD Host])
            AM_CONDITIONAL([IS_FREEBSD],true)
            BP_ADD_LDFLAG([-L/usr/local/lib])
                ;;
esac

Makefile.am

lib_LTLIBRARIES=mylib.la
mylib_la_SOURCES=a.cpp \
                 b.cpp

if IS_FREEBSD
    mylib_la_SOURCES+=freebsd/c.cpp
else
    mylib_la_SOURCES+=linux/c.cpp
endif

当我运行 automake 时，它会失败，并显示以下消息：

Makefile.am: object `c.lo' created by `linux/c.cpp' and `freebsd/c.cpp'

Any ideas on how to configure automake to recognize thisconditional Even in the Makefile.in build process?

如果文件具有不同的名称，则此方法有效，但它是 C++ 代码，并且我试图保持文件名与类名相同。

提前致谢！

原文

I've a C++ autoconf managed project that I'm adapting to compile on FreeBSD hosts.
The original system was Linux so I made one AM_CONDITIONAL to distinguish the host I'm building and separate the code into system specific files.

configure.ac


AC_CANONICAL_HOST
AM_CONDITIONAL([IS_FREEBSD],false)
case $host in
        *free*)    
            AC_DEFINE([IS_FREEBSD],[1],[FreeBSD Host])
            AM_CONDITIONAL([IS_FREEBSD],true)
            BP_ADD_LDFLAG([-L/usr/local/lib])
                ;;
esac

Makefile.am


lib_LTLIBRARIES=mylib.la
mylib_la_SOURCES=a.cpp \
                 b.cpp

if IS_FREEBSD
    mylib_la_SOURCES+=freebsd/c.cpp
else
    mylib_la_SOURCES+=linux/c.cpp
endif

When I run automake it fails with this kind of message:

Makefile.am: object `c.lo' created by `linux/c.cpp' and `freebsd/c.cpp'

Any ideas on how to configure automake to respect this conditional even in the Makefile.in build proccess?

I this works if the files have diferent names, but it's c++ code and I'm trying to keep the filenames the same as the class name.

Thanks in advance!

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

温折酒 2024-07-28 13:31:35

除了subdir-objects之外，另一个选择是为每个子项目提供一些自定义的每个项目构建标志。当您执行此操作时，automake 会更改其 *.o 命名规则，将目标名称添加到模块名称前面。例如，这

mylib_la_CXXFLAGS=$(AM_CXXFLAGS)
mylib_la_SOURCES=a.cpp b.cpp

将产生输出文件 mylib_la-ao 和 mylib_la-bo，而不是 ao 和 bo 因此，您可以拥有两个具有相同输出目录的不同项目，每个项目都有一个 b.cpp 文件，而不是他们的输出有冲突。

请注意，我通过将项目特定的 CXXFLAGS 设置为 automake 已经要使用的值 AM_CXXFLAGS 来完成此操作。 Automake 不够聪明，无法检测到此技巧并使用较短的 *.o 名称。如果您确实需要每个项目的构建选项，您当然可以这样做而不是使用此技巧。

有一个整个列表 automake 变量，当设置在每个 -可执行的基础上，给出同样的效果。例如，也许一个子项目已经需要特殊的链接标志，所以你给它类似的东西：

mylib_la_LDFLAGS=-lfoo

这将为你提供前缀 *.o 文件，就像 AM_CXXFLAGS 技巧一样，只是现在你“合法”使用此功能，而不是欺骗 automake 来做这件事。

顺便说一句，仅根据所构建的操作系统来更改程序的构建方式是不好的 autoconf 风格。良好的 autoconf 风格是仅检查特定平台功能，而不是整个平台，因为平台会发生变化。今天，FreeBSD 可能是某种方式，但也许在下一个版本中，它会复制 Linux 的一项功能，从而消除您以两种不同方式构建程序的需要。或者，也许您今天使用的功能已被弃用，并将在下一版本中删除。

在 autotools、grasshopper 中有四十年的可移植 Unix 编程智慧。我上面给出的“也许”已经发生在过去，并且肯定会再次发生。测试各个功能是应对不断变化的平台的最灵活的方法。

您也可以通过这种方法获得意想不到的好处。例如，也许您的程序需要两个不可移植的功能来完成其工作。假设在 FreeBSD 上，这些是 A 和 B 功能，在 Linux 上，它们是 X 和 Y 功能； A 和 X 是类似的机制，但具有不同的接口，B 和 Y 也相同。功能 A 可能来自原始 BSD，并且位于 Solaris 中，因为它具有来自 80 年代 SunOS 的 BSD 根源，并且 Solaris 也有Y 功能来自 90 年代初基于 System V 的重新设计。通过测试这些功能，您的程序也可以在 Solaris 上运行，因为它具有您的程序所需的功能，只是与 FreeBSD 和 Linux 上的组合不同。

Another option, besides subdir-objects, is to give each sub-project some custom per-project build flags. When you do this, automake changes its *.o naming rules to prepend the target name onto the module name. For example, this:

mylib_la_CXXFLAGS=$(AM_CXXFLAGS)
mylib_la_SOURCES=a.cpp b.cpp

will result in the output files mylib_la-a.o and mylib_la-b.o, rather than a.o and b.o. Thus you can have two different projects with the same output directory that each have, say, a b.cpp file, and not have their outputs conflict.

Notice that I did this by setting the project-specific CXXFLAGS to the values automake was already going to use, AM_CXXFLAGS. Automake isn't smart enough to detect this trick and use the shorter *.o names. If it happens that you do need per-project build options, you can of course do that instead of this hack.

There's a whole list of automake variables that, when set on a per-executable basis, give this same effect. So for instance, maybe one sub-project needs special link flags already, so you give it something like:

mylib_la_LDFLAGS=-lfoo

This will give you the prefixed *.o files just as the AM_CXXFLAGS trick did, only now you are "legitimately" using this feature, instead of tricking automake into doing it.

By the way, it's bad autoconf style to change how your program builds based solely on the OS it's being built for. Good autoconf style is to check only for specific platform features, not whole platforms, because platforms change. FreeBSD might be a certain way today, but maybe in the next release it will copy a feature from Linux that would erase the need for you to build your program two different ways. Or, maybe the feature you're using today is deprecated, and will be dropped in the next version.

There's forty years of portable Unix programming wisdom in the autotools, grasshopper. The "maybes" I've given above have happened in the past, and will certainly do so again. Testing individual features is the nimblest way to cope with constantly changing platforms.

You can get unexpected bonuses from this approach, too. For instance, maybe your program needs two nonportable features to do its work. Say that on FreeBSD, these are the A and B features, and on Linux, they're the X and Y features; A and X are similar mechanisms but with different interfaces, and the same for B and Y. It could be that feature A comes from the original BSDs, and is in Solaris because it has BSD roots from SunOS in the 80's, and Solaris also has feature Y from it's System V based redesign in the early 90's. By testing for these features, your program could run on Solaris, too, because it has the features your program needs, just not in the same combination as on FreeBSD and Linux.

回复收藏 0 原文