ExternalProject Build Byproduct Path

Code
1

I am using the ExternalProject for two projects and in both cases I need to list build byproducts. The problem is that in both cases I need to list them relative to the build. Thinking about this, it makes little sense to have build byproducts that are not relative to the build. On the other hand, getting the PREFIX property via ExternaProject_Get_Property can only be done after the external project is added, but I want to specify the build byproducts as I am adding the project so there is a chicken & egg problem. Why not make the build byproducts relative to the prefix by default?

2

Not all BYPRODUCTS are guaranteed to be in the install tree. For example, I know that sometimes the build tree of the ExternalProject gets used instead of the install tree at times. Wouldn’t it be better to instead just support <PREFIX> and <BINARY_DIR> expansions in the arguments (keeping relative paths as they are)?

3

I know they are not guaranteed to be in the install (or the build) tree, I was just saying they should default to that. But your suggestion of expanding variables makes more sense yet it will ultimately not support what I would like to see. Currently I am doing

set(FOO_BYPRODUCTS foo bar)
list(TRANSFORM FOO_BYPRODUCTS PREPEND "<foo_path>")
ExternalProjectAdd(foo
...
BUILD_BYPRODUCTS "${FOO_BYPRODUCTS}")

add_executable(bar bar.cpp "${FOO_BYPRODUCTS}")

where I had to find foo_path manually by trial and error. Your suggestion, if I understand correctly, would still require me to use of list, but then I would also want those expanded names to be available at the add_executable call. With some sort of default, I could probably do this with

set(FOO_BYPRODUCTS foo bar)
ExternalProjectAdd(foo
...
BUILD_BYPRODUCTS "${FOO_BYPRODUCTS}")
ExternalProject_Get_Property(foo BUILD_BYPRODUCTS)
add_executable(bar bar.cpp "${BUILD_BYPRODUCTS}")

where the BUILD_BYPRODUCTS variable now has all the expanded names. What do you think?

4

I think it likely that the BUILD_BYPRODUCTS <foo_path>/foo <foo_path>/bar and ExternalProject_Get_Property() together would work. The relative paths are kind of ambiguous: what are they relative to?

5

The binary dir of the external project would be a sensible default, I think.

6

Possibly. But <INSTALL_DIR> may be useful as well. Either way, I think this is ready for a write up as an issue (we have the “safe” default of requiring an absolute path for now if the default for relative is undecidable) since there’s a use case.