What makes that really hostile? Isn't that just adding an extra path for it to check at link time? If it doesn't find it in that path, then you can always just pass the link flags directly to shards build still, right?
Matthew Berry how can you say that that flag is supposed to check something at link time, if exactly that is already the job of the -L flag?
-rpath . has a very simple effect: append the value
. to the "rpath" field of the final ELF executable (empty by default). so you're saying: "if you use my library, you must accept a custom and rare value of rpath for your executable." then, what is done at run time with that field is to check those paths for libraries that were linked against and use them. I'd (strongly) say that it should be up to the developer of the executable to decide that allowing overrides of any referenced lib from current directory is ok. it works only for particular models of deployment and is a question of security as well.
@[Link(ldflags: "-Wl,-rpath .")] lib DoesntMatterWhatNameIsHere end
$(CXX)lines and use
cl.exe, it cannot accept GCC-like flags
shards installtakes care of everything unless you want to override a value provides the best DX even if the build script is more complex. I doubt I'd have half as many users if it required: manually check your distro version. If it's >= x
installelse download and build it yourself.
Yes. If only
postinstall: linux-musl: ./build/linux-musl.sh # needs variant for some reason linux: ./build/linux.sh windows-msvc: ./build/windows-mingw.cmd windows-mingw: ./build/windows-mingw.cmd posix-default: cd build/posix && make windows-default: cd build/windows && make
And tried keys in order of most specific to less specific arch trying
windows-default 2nd to last before