Hi,
I’ve been trying to understand the following issue for the last several hours, but now it’s time to call in the cavalry… 
In the project that I’m working on at the moment (atlas / atlasexternals · GitLab) we build a bunch “external projects” that our “main project” would eventually depend on. The way we do this is a bit complicated, because for historical reasons we needed to ensure that in our build directory we would produce binaries with the same layout that they would eventually have after being installed. (Long story…)
When using ExternalProject_Add, the logic we/I came up with is that:
- The
ExternalProject_Add(...)command installs the particular “external” into its own dedicated directory inside of the build directory; - From there I copy everything into the “common directory” of the build directory as part of the build;
- Using install(DIRECTORY …) the contents of the “custom directory” are installed into “
.”.
See for instance: External/CLHEP/CMakeLists.txt · master · atlas / atlasexternals · GitLab
Note that for the “second step” of the previous description we use a custom “buildinstall” step like: External/CLHEP/CMakeLists.txt · master · atlas / atlasexternals · GitLab
To complicate things even further, we also override the default behaviour of CPack normally, but that’s a long story of its own. The thing is, with that “overridden behaviour” we’ve been using CPack happily for years for producing RPM and TGZ packages from our project(s). But (again because of a complicated set of reasons) now I’m trying to make our build work with a “more default” setup of CPack. (The latest code changes that I’m working on right now, are in: CPack Cleanup, master branch (2023.06.02.) (!1015) · Merge requests · atlas / atlasexternals · GitLab) And I bumped into a behaviour that I can’t manage to understand. 
When generating an RPM package, I end up with a directory structure like the following:
[bash][pcadp04]:AthSimulationExternals > tree -L 4 _CPack_Packages/Linux/RPM/AthSimulationExternals_24.0.6_x86_64-centos
9-gcc11-opt/
_CPack_Packages/Linux/RPM/AthSimulationExternals_24.0.6_x86_64-centos9-gcc11-opt/
├── mnt
│ └── hdd1
│ └── krasznaa
│ └── projects
└── usr
└── AthSimulationExternals
└── 24.0.6
└── InstallArea
8 directories, 0 files
[bash][pcadp04]:AthSimulationExternals >
While I get a much more reasonable layout while I generate a TGZ package.
[bash][pcadp04]:AthSimulationExternals > tree -L 4 _CPack_Packages/Linux/TGZ/AthSimulationExternals_24.0.6_x86_64-centos9-gcc11-opt
_CPack_Packages/Linux/TGZ/AthSimulationExternals_24.0.6_x86_64-centos9-gcc11-opt
└── usr
└── AthSimulationExternals
└── 24.0.6
└── InstallArea
4 directories, 0 files
[bash][pcadp04]:AthSimulationExternals >
The “unnecessary directories” that I get with the RPM generation are copies of the “separate installation directories” that the “buildinstall” steps and the install(DIRECTORY ...) calls use as sources. And I can just not figure out why this behaviour is happening.
Note that I only see this for the externals where the “buildinstall machinery” is at play. For Makefile based projects like External/Gdb/CMakeLists.txt · master · atlas / atlasexternals · GitLab, where this behaviour is achieved simply by defining a multi-step installation command, I don’t get any weird behaviour with CPackRPM. 
So it’s somehow the custom step in ExternalProject_Add(...) that makes CPackRPM’s installation step behave in a weird way. But I can just not figure out why… 
I know that our code is a bit too complicated to look at without a lot more context. I’m mainly just hoping that somebody may have an idea why custom steps with ExternalProject_Add(...) may lead to a weird behaviour with CPackRPM…
Cheers,
Attila
