Currently, the particular environment variables used by linkers are tool-dependent, which makes it difficult to provide a generic way to set them via the toolchain (e.g. the way compile_options() works). It would be nice if we could change this so that they're more consistent. These are the environment variables currently in use:
jvm
dynamic: linker=JAR flags=JARFLAGS
static: N/A
native (cc)
dynamic: linker=N/A[1] flags=LDFLAGS libs=LDLIBS
static: linker=AR flags=ARFLAGS
native (msvc)
dynamic: linker=VCLINK flags=LDFLAGS libs=LDLIBS
static: linker=VCLIB flags=LIBFLAGS
[1]: cc-style linking usually happens with the compiler executable (eg gcc), but you can often set the linker via -fuse-ld.
The cc-style flags are sort of the "gold standard", since bfg9000 is designed around making things somewhat POSIX-y, even on Windows. However, AR and ARFLAGS seem too implementation-specific, and using LD in place of VCLINK could cause some confusion since it wouldn't affect the actualld command for a cc-style build.
Another, less-critical issue is that the native family assumes a C-style build process, which may not apply to other natively-compiled languages. We should look at Rust to see how their build process works and how it would map onto bfg's "families".
One option would be to figure out a way to map the LD env var to -fuse-ld (or providing a warning when building with a cc-style tool?) and then moving all the native variables to cc-style. It should be fairly straightforward to deprecate the msvc-style variables, especially since the non-cc-style ones are unique to bfg.
Currently, the particular environment variables used by linkers are tool-dependent, which makes it difficult to provide a generic way to set them via the toolchain (e.g. the way
compile_options()works). It would be nice if we could change this so that they're more consistent. These are the environment variables currently in use:jvmJARflags=JARFLAGSnative(cc)LDFLAGSlibs=LDLIBSARflags=ARFLAGSnative(msvc)VCLINKflags=LDFLAGSlibs=LDLIBSVCLIBflags=LIBFLAGS[1]: cc-style linking usually happens with the compiler executable (eg
gcc), but you can often set the linker via-fuse-ld.The cc-style flags are sort of the "gold standard", since bfg9000 is designed around making things somewhat POSIX-y, even on Windows. However,
ARandARFLAGSseem too implementation-specific, and usingLDin place ofVCLINKcould cause some confusion since it wouldn't affect the actualldcommand for a cc-style build.Another, less-critical issue is that the
nativefamily assumes a C-style build process, which may not apply to other natively-compiled languages. We should look at Rust to see how their build process works and how it would map onto bfg's "families".One option would be to figure out a way to map the
LDenv var to-fuse-ld(or providing a warning when building with a cc-style tool?) and then moving all the native variables to cc-style. It should be fairly straightforward to deprecate the msvc-style variables, especially since the non-cc-style ones are unique to bfg.