Posted Mon, 20 Oct 2014 07:14:56 GMT in reply to
Shammah Chancellor
On Wed, 15 Oct 2014 16:35:00 -0400, Shammah Chancellor wrote:
I am wondering what the proper way to deal with external non-D
dependencies is. For example, libd-llvm uses a lot of libraries from
LLVM whose library path changes from machine to machine, and some of
the list of 30 libraries changes as well. They have a nice
configuration tool llvm-config which emits ldflags which are very nice
to use from makefiles but I don't see any way to obtain this
information from within the dub.json.
Do I essentially need to make an autotools-esque script to generate the
dub.json? That seems to be at odds with the ability to register
packages.
-S
It would be almost possible using a "preGenerateCommands" entry. I'm wondering if it would make sense to let the pre-generate commands work with the same environment that the main DUB process uses. With a feature to split up environment variables it would then be possible to do something like this:
{
"preGenerateCommands-posix": ["export LLVM_LD_FLAGS=`llvm-config`"],
"lflags-posix": [{"function": "splitArgs", "value": "$LLVM_LD_FLAGS"}]
}
I'm still skeptical allowing to directly embed program executions into the build configuration fields. But generally, if LLVM is installed, doesn't it put the libraries into one of the standard global library folders, as everyone else does? In that case it should be legal to just statically put the output of llvm-config into the "libs" field, shouldn't it?
