I have a couple of executables that I want to be able to use the same libraries. After building, I want the tree to look like this (simplified example):
Root
|--Prog1
| |--src
| |--obj
| |--Prog1.gpr
| |--Prog1.exe
| |--libLib1.dll
|
|--Prog2
| |--src
| |--obj
| |--Prog2.gpr
| |--Prog2.exe
| |--libLib1.dll
|
|--Lib1
|--src
|--obj
|--Lib1.gpr
Normally, the simple thing to do is build a single copy of Lib1 and let each refer to that build with a relative reference to the location of the Lib1.gpr. But I want each executable to have its own dependencies included in its own directory.
If I put this in Lib1.gpr, it'll put the libLib1.dll in Prog1 only:
for Library_Dir use "../Prog1";
Which is not what I want, because then Prog2 won't be able to use it.
If I pass --relocate-build-tree=. at command line, it will move the whole build tree, which is also not what I want (it also complains about not being able to relocate deeper than object directory).
I tried just specifying Library_Dir for one of the two and doing a dumb file copy to copy it to the other before running that gpr, and this worked at first but is becoming unwieldy as the overall project gets more complex. I thought about trying to parameterize out the "for Library_Dir" but I'm not convinced that won't result in only one location being updated (after all, the source won't change between the two builds).
Why not just leave it in Lib1 and let each refer to the save copy? For binary distribution reasons--certain binaries are development support tools and not intended for distribution, while the others are each separate projects that should be distributed separately.
Is there a way gprbuild can be configured to produce a library and place it in two target directories?
for Library_Directory use
clause in the gpr file.