我有以下项目结构,其中每个.adb
文件都是一个独立的可执行文件,不会,也不会依赖任何其他:
project/
├── project.gpr
├── bin/
│ ├── bar
│ ├── baz
│ └── foo
├── obj/
│ └── .o's, .ali's, etcetera
└── src/
├── bar.adb
├── baz.adb
└── foo.adb
这是project.gpr
:
project Project is
for Source_Dirs use ("src");
for Object_Dir use "obj";
for Exec_Dir use "bin";
for Main use ("src/foo.adb", "src/bar.adb", "src/baz.adb");
end Project;
目前gprbuild
和gprclean
完全符合我的要求,但src/
下的文件数量可能会增加到数百个。
有没有办法告诉GPRbuild,.adb
下的每个src/
文件都应被视为Main
目标而不明确列出其中的每一个?
答案 0 :(得分:1)
由于使用的是GPR,因此您可以考虑使用汇总项目。
您为每个要生成的可执行文件定义1 GPR。 然后,您定义1个汇总GPR,以全部构建它们。
我相信您非常接近in this link
所述的用例报价:
大多数情况下,应用程序被组织为模块和子模块,这些模块和子模块非常方便地表示为项目树或图(根项目A包含每个模块的项目(例如B和C),而子项目又包含用于子模块。
很多时候,模块会构建自己的可执行文件(例如,用于测试目的)或库(用于在各种情况下更容易重用)。
但是,如果您通过gnatmake或gprbuild构建项目,则使用类似的语法
gprbuild -PA.gpr
这将仅重建项目A的主程序,而不重建导入的项目B和C的主程序。因此,您必须生成几个gnatmake命令,每个项目一个,以生成所有可执行文件。这有点不方便,但更重要的是效率低下,因为gnatmake需要做重复的工作来确保源是最新的,并且在使用-j开关时无法轻松地并行编译事物。
在构建项目时,也会始终重建库。
因此,您可以定义将A,B和C分组的聚合项目Agg。然后,当您使用
进行构建时
gprbuild -PAgg.gpr
这将构建来自A,B和C的所有电源。
aggregate project Agg is
for Project_Files use ("a.gpr", "b.gpr", "c.gpr");
end Agg;
当然,您最终需要为每个主要对象创建1个GPR的开销很小,但是清楚地定义每个已构建的人工制品似乎很合逻辑,尤其是如果它们会
从不互相依赖
如您在问题中所述。
但是,似乎GPR接受了GPR聚合的语法,其中考虑了给定目录中的所有GPR。请参阅here,尤其是here
Project_Files:
此属性是强制性的。它指定在聚合中分组的组成.gpr文件的列表。该列表可能为空。项目文件可以是除配置项目或抽象项目以外的任何项目。它们可以是其他汇总项目。对标准项目进行分组时,既可以具有项目导入闭包的根(并且不需要指定其所有导入的项目),也可以具有闭包内的任何项目。
基本思想是指定所有具有要构建和链接的主程序或要构建的库的项目。您可以指定不使用Main属性或
Library_*
属性的项目,结果将是建立其所有源文件(而不仅仅是其他项目所需的文件)。[...]
路径也可以包含
*
和**
的glob模式。后者表示将在任何子目录中(递归)搜索匹配的文件。**
模式只能出现在目录部分的最后一个位置(即支持a/**/*.gpr
,但不支持**/a/*.gpr
)。以**
开头的模式等同于以./**
开头的模式。目前,模式
*
仅在文件名部分中允许,而在目录部分中则不允许。这主要是出于效率方面的考虑,以限制所需的系统调用次数。以下是一些示例:
for Project_Files use ("a.gpr", "subdir/b.gpr");
-- two specific projects relative to the directory of agg.gpr
for Project_Files use ("/.gpr");
-- all projects recursively
答案 1 :(得分:0)
class A
等同于要求GPRBuild编译所有可用的源文件。