The Crystal programming language | http://crystal-lang.org | Fund Crystal's development: http://is.gd/X7PRtI | Docs: http://crystal-lang.org/docs/ | API: http://crystal-lang.org/api/
the second one overwrites the first
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?
writing -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.
if you still want to hardcode this addition in source code, that's ok, but it should be done in the main executable's source code. can be done as such, I'm pretty sure:
@[Link(ldflags: "-Wl,-rpath .")]
lib DoesntMatterWhatNameIsHere
end
and that can't be applied on Windows, of course
@didactic-drunk: well, building a whole C library in your postinstall is the problem
how did this https://libsodium.gitbook.io/doc/installation#compilation-on-unix-like-systems get turned into that set of large scripts? :o https://github.com/didactic-drunk/sodium.cr/tree/master/build
i don't know really... I don't have a verdict on what's "wrong" to do in postinstall, but indeed a cross-platform postinstall is near-impossible to achieve at the moment
@mattrberry: that wasn't really my point. let's say i want to use your "crystal-imgui-backends". i don't want my executable to have a tweaked rpath. i have no options to solve that.
@mattrberry: awh the external libs are too numerous, i couldn't handle it :( i think i'm giving up on the Windows stuff
ultimately the problem here is that for my Windows usages I did not rely on Makefile at all, but here it would be way too much work to rework it to a separate script
compared to https://github.com/oprypin/crystal-imgui-sfml/blob/master/make.cmd
compared to https://github.com/oprypin/crystal-imgui-sfml/blob/master/make.cmd
@mattrberry: yes i think it will not be possible to use the makefile on windows. look, it's building some weird lib file https://github.com/oprypin/crab/runs/2814402132?check_suite_focus=true#step:9:56
other than that, this is very close to working
Hmm I’m on mobile, but maybe that’s because I’m linking it back here? https://github.com/mattrberry/crystal-imgui-backends/blob/16a576200f366c0c6aec1fc5033108ae1a975f5e/Makefile#L40
the file is "weird" because g++ is used unconditionally for that build, whereas everything else is managed by MSVC
well i deleted that part anyway, so that literally can't be it
the main remaining thing, as I said, is to find an alternative to all these
$(CXX) lines and use cl.exe instead of g++. https://github.com/mattrberry/crystal-imgui-backends/blob/16a576200f366c0c6aec1fc5033108ae1a975f5e/Makefile#L45
i have no idea if that's viable within the Makefile. i opted to go for a separate build script on Windows. https://github.com/oprypin/crystal-imgui-sfml/blob/master/make.cmd
Hmm I don’t know Makefile super well, but that’s supposed to be defined as the c++ compiler for that system, right? For much of the makefile, I borrowed it straight from the imgui example here https://github.com/ocornut/imgui/blob/master/examples/example_sdl_opengl3/Makefile
yeah you end up using the C++ compiler for that MinGW (or whatever) environment
that Makefile ends up referring to POSIX tool clones
and it's moot anyway because even if
CXX=cl.exe , it cannot accept GCC-like flags
Isn’t that why it sets the windows flags here? https://github.com/ocornut/imgui/blob/d0c6dd9bafcfb0845153080fe00d74e62ad28c86/examples/example_sdl_opengl3/Makefile#L97
Crystal works only with cl.exe, doesnt work with MinGW-GCC
but they do also have support for cl.exe
Ah now we’re getting even further into the realm that I know absolutely nothing about :/ Are those just two different c++ compilers for windows? I’ll be able to grab my laptop in a couple hours to look a little deeper too, although I don’t have windows there either :/
Matthew Berry: yeah they are. cl.exe is by Microsoft, where as MinGW is a collection of ports of POSIX tools to Windows; they end up being partly in an emulated environment or something weird
so yeah this is quite ugly and way harder than i made it seem
Ah, well again thank you tons for taking a look!! Maybe someday it’ll be easier to port :) Appreciate you trying :)
@oprypin:matrix.org Attempting to improve UX (developer experience DX, is that thing?). There are 3 unix use cases. 1) Building a rpm/deb package (or personal executable) that relies on the distribution packaged libraries. 2) Building a run on any distro binary that can't rely on a system installed libsodium. 3) Same as 1 but the system libsodium is ancient and can't be used (This is very common). The build scripts check the system version (but allow overrides) and them by default if new enough otherwise download and build the version tested with sodium.cr. None of this is a concern for windows which never has a packaged libsodium
@oprypin:matrix.org
shards install takes 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 install else download and build it yourself.
i see. well, maybe my main dissatisfaction comes from how rigid postinstall is. any tiniest problem and everything just bails out
and you're basically taking on a task of maintaining a fully universal build of a lib.
Yes. If only postinstall allowed
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 && makeAnd tried keys in order of most specific to less specific arch trying posix-default or windows-default 2nd to last before default.
@didactic-drunk: well it looks like you're already miles ahead of the rest in terms of thinking this through. I'd support this
How have you all been?