代码之家  ›  专栏  ›  技术社区  ›  Mr Fooz

自动工具能否创建多平台makefiles

  •  2
  • Mr Fooz  · 技术社区  · 16 年前

    从我浏览autotools文档中可以看出,与我想要的最接近的是有N个独立的项目副本,每个副本都有自己的makefile。这对于测试和开发来说似乎有点不太理想,因为(a)我需要在所有不同的副本中不断传播代码更改,(b)重复项目这么多次会浪费大量空间。有更好的办法吗?

    编辑:

    我已经推出自己的解决方案一段时间了,我有一个奇特的makefile和一些perl脚本来查找各种第三方库版本,等等。因此,我对其他非自动工具解决方案持开放态度。对于其他构建工具,我希望它们对于最终用户来说非常容易安装。这些工具还需要足够智能,以便在不遇到大量麻烦的情况下查找各种第三方库和头。我主要是在寻找一个linux解决方案,但是一个同样适用于Windows和/或Mac的解决方案将是一个额外的收获。

    4 回复  |  直到 16 年前
        1
  •  6
  •   Jonathan Leffler    16 年前

    如果你的问题是:

    我可以在某台机器上使用autotools创建一个通用makefile,该文件将在所有其他机器上运行吗?

    我可以使用autotools来配置需要在不同机器上运行的软件吗?我的插件所使用的主软件的不同版本,以及各种第三方库,更不用说32位与64位的问题了?

    那么答案是“是”。自动工具的设计就是为了能够做到这一点。此外,它们在Unix、Linux、MacOS X和BSD上工作。

    另一方面,我不会尝试发布一个适合所有客户机器和环境的makefile;有太多的可能性,这是不明智的。但autotools为我(和我的用户)处理细节。他们所做的只是:

    ./configure
    

    这比解决如何编辑makefile更容易。(哦,在最初的10年里,程序是手工配置的。尽管我设置了相当好的默认设置,但人们很难这样做。这就是为什么我转向了自动配置:它让人们更容易安装。)


    32位和64位版本的插件是否需要单独构建?(我想是的,但你可能会让我吃惊。)所以你需要提供一种机制让用户说

    ./configure --use-tppkg=/opt/tp/pkg32-1.0.3
    

    (其中tppkg是第三方软件包的代码,位置可由用户指定。)但是,请记住可用性:用户选择的此类选项越少 提供更好的服务;与此相反,不要硬编码应该是可选的东西,例如安装位置。无论如何,在默认位置查看-这很好。默认为你找到的东西的零碎部分。也许如果您同时找到32位和64位版本,那么您应该同时构建这两个版本——尽管这需要仔细构建。您可以始终回显“检查TP包…”,并指出您找到了什么以及在哪里找到的。然后安装程序可以更改选项。确保您的文档在' ./configure --help "有什么选择,;这是标准的自动工具实践。

    不要做任何互动的事情;配置脚本应运行,并报告其功能。Perl Configure 脚本(请注意大写字母-它是一个完全独立的自动配置系统)是剩下的少数几个高度交互的配置系统之一(这可能主要是因为它的传统;如果重新开始,它很可能是非交互的)。与非交互式系统相比,此类系统的配置更麻烦。

    交叉编译是困难的。谢天谢地,我从来不需要这么做。


    福兹先生还评论道:

    谢谢你的额外评论。我要找的东西是:

    ./configure --use-tppkg=/opt/tp/pkg32-1.0.3 --use-tppkg=/opt/tp/pkg64-1.1.2
    

    嗯,我相信这是可以做到的;我不太确定与两个单独的配置运行(中间有一个完整的重建)相比是否值得这样做。您可能希望使用:

    ./configure --use-tppkg32=/opt/tp/pkg32-1.0.3 --use-tppkg64=/opt/tp/pkg64-1.1.2
    

    这表示两个单独的目录。您必须决定如何进行构建,但您可能会有两个子目录,例如' obj-32 obj-64

    FLAGS_32 = ...32-bit compiler options...
    FLAGS_64 = ...64-bit compiler options...
    
    TPPKG32DIR = @TPPKG32DIR@
    TPPKG64DIR = @TPPKG64DIR@
    
    OBJ32DIR = obj-32
    OBJ64DIR = obj-64
    
    BUILD_32 = @BUILD_32@
    BUILD_64 = @BUILD_64@
    
    TPPKGDIR =
    OBJDIR   =
    FLAGS    =
    
    all:    ${BUILD_32} ${BUILD_64}
    
    build_32:
        ${MAKE} TPPKGDIR=${TPPKG32DIR} OBJDIR=${OBJ32DIR} FLAGS=${FLAGS_32} build
    
    build_64:
        ${MAKE} TPPKGDIR=${TPPKG64DIR} OBJDIR=${OBJ64DIR} FLAGS=${FLAGS_64} build
    
    build:  ${OBJDIR}/plugin.so
    

    这假设插件将是一个共享对象。这里的想法是,autotool将检测第三方软件包的32位或64位安装,然后进行替换。如果32位包是必需的,则BUILD_32宏将设置为BUILD_32,否则为空;BUILD_64宏的处理方式与此类似。

    当用户运行 make all ,它将首先生成build_32目标,然后生成build_64目标。要构建build_32目标,它将重新运行 make 并为64位生成配置标志。重要的是,受32位与64位构建影响的所有标志都是在 制作 .c.o

    ${CC} ${CFLAGS} -o ${OBJDIR}/$*.o -c $*.c
    

    宏CFLAGS将包括处理位的${FLAGS}值(例如, FLAGS_32 = -m32 , and so when building the 32-bit version, 标志=-m32 would be included in the CFLAGS`宏。

        2
  •  5
  •   Mihai Limbășan    16 年前

    据我所知,你不能那样做。但是,您是否仍在使用自动工具?两者都不是 CMake 也没有 SCons 选择?

        3
  •  1
  •   Jonathan Leffler    16 年前

    SCons .

    有关此主题的一些文章: 1 2

    编辑:

    env.ParseConfig('pkg-config --cflags --libs glib-2.0')
    

    环境 ).别忘了 User Guide PyInstaller 或者类似的。

    与之相比 make ,您使用Python,因此是一种完整的编程语言!记住这一点,你可以做任何事情(或多或少)。

        4
  •  0
  •   j0k gauthamp    12 年前

    以下是可能的:

    mkdir build1 build2 build3
    cd build1
    ../configure $(YOUR_OPTIONS)
    cd build2
    ../configure $(YOUR_OPTIONS2)
    [...]
    

    然后,您甚至可以通过运行

    make -C build1 -C build2 -C build3