crystal-lang/crystal

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/

didactic-drunk

@didactic-drunk

My message describes one example. I think we tried 3 or more different solutions but crystal would only accept "compiles everywhere, runs uncertainly". An example would be the windows sid. Process.sid should work on windows only. With the official crystal way it's a runtime error when called. With our if you call it on a non windows system the program won't compile. I think that fits better with the crystal philosophy of "Crystal is statically type checked, so any type errors will be caught early by the compiler rather than fail on runtime." (taken from crystals web page).

Also, how do you know what a supported platform is and should you need to know for every API. Feature checking with respond_to allows for future proofing. Example: Linux supports open45, later FreeBSD adds support, and finally Mac/OS 15 years later. The shard wrapping open45 can add os support incrementally while every crystal program using the shard can keep the same feature check without changing their code, just update to a new shard for new os support.

From IRC (bridge bot)

@FromIRC

<postmodern> hmm yeah, handling platform-specific code vs. platform agnostic code will eventually become a problem

<postmodern> i guess shards may need to add a feature to specify that a shard only works on a certain platform

didactic-drunk

@didactic-drunk

The mutual conclusion is platform specific code will go in shards. They won't take platform specific code and we can't make certain types of programs without them. Like ioctl

From IRC (bridge bot)

@FromIRC

<postmodern> once windows support get's finalized, i wouldn't be surprised if we see a cyrstal-windows github org, for crystal shards that access private Windows APIs and libraries.

oprypin

@oprypin:matrix.org

[m]

@mattrberry: could you point out to me that project that I wanted to add Windows support to? and is it in a good working shape as is?

Matthew Berry

@mattrb:matrix.org

[m]

Thank you again for taking a look!! This is the project https://github.com/mattrberry/crab
It’s currently in working condition on Linux, but breaking on Mac because I didn’t link opengl properly in the imgui backends package https://github.com/mattrberry/crystal-imgui-backends

Matthew Berry

@mattrb:matrix.org

[m]

It currently builds on Linux with just a shards build because I set the rpath in the link flags in the backends library :p

didactic-drunk

@didactic-drunk

@oprypin:matrix.org Are you testing windows gh actions integration?

oprypin

@oprypin:matrix.org

[m]

@didactic-drunk: well not really testing, i know it works

didactic-drunk

@didactic-drunk

@oprypin:matrix.org I'd like to get sodium on windows, but it uses shell scripts to download & build libsodium. If you have recommendations I'll take them

From IRC (bridge bot)

@FromIRC

<straight-shoota> @didactic-drunk: https://libsodium.gitbook.io/doc/installation#compilation-on-windows

didactic-drunk

@didactic-drunk

Downloading on windows? How to handle multiple platforms in shard.yaml - postinstall?

Kaia Leahy

@tenebrousedge

sup y'all

oprypin

@oprypin:matrix.org

[m]

It currently builds on Linux with just a shards build because I set the rpath in the link flags in the backends library :p

ow.. that's what i said shouldn't be done. it's really hostile.

anyway.. I'll get around to this tomorrow. today i kinda disappeared

Matthew Berry

@mattrberry

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?

Maybe I'm missing something, but I don't see a harm in setting it?

Unrelated: Am I missing something silly here? This isn't matching my expectation https://play.crystal-lang.org/#/r/bbpq

I would have expected the self.new in SDLOpenGLImGuiFrontend to be called

I can totally just do it a different way, I just expected different behavior

Matthew Berry

@mattrberry

Ah I'm guessing that's because the self.new and self.initialize have the same args

Kaia Leahy

@tenebrousedge

@mattrberry https://play.crystal-lang.org/#/r/bbpw

the second one overwrites the first

Matthew Berry

@mattrberry

Yeah that makes sense, that was my suspicion. I don't know how I'd actually expect it to work if not like this tbh haha

oprypin

@oprypin:matrix.org

[m]

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.

Oleh Prypin

@oprypin

agh tagging you didn't work properly. trying again. @mattrberry

oprypin

@oprypin:matrix.org

[m]

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

oprypin

@oprypin:matrix.org

[m]

@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

Matthew Berry

@mattrberry

@oprypin Maybe I’m just being naive? I figure since they’re already building my code, they’re trusting that the code I’ve written isn’t malicious. What makes me setting the rpath any more dangerous since they’re already building my code anyway?

oprypin

@oprypin:matrix.org

[m]

@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.

Matthew Berry

@mattrberry

What’s the harm in the tweaked rpath though? And couldn’t they set it in their own application as well to override, in theory if they really wanted to? I’m not trying to argue btw, maybe I’m just missing something?

oprypin

@oprypin:matrix.org

[m]

@mattrberry: awh the external libs are too numerous, i couldn't handle it :( i think i'm giving up on the Windows stuff

https://github.com/oprypin/crab/compare/gh-ci
https://github.com/oprypin/crystal-imgui-backends/compare/gh-ci
this is as far as i got
https://github.com/oprypin/crab/actions/runs/933471400

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

Matthew Berry

@mattrberry

@oprypin Ahh no worries, well thank you tons for starting on it at least!!

oprypin

@oprypin:matrix.org

[m]

@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

Matthew Berry

@mattrberry

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

oprypin

@oprypin:matrix.org

[m]

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

Matthew Berry

@mattrb:matrix.org

[m]

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

oprypin

@oprypin:matrix.org

[m]

yeah you end up using the C++ compiler for that MinGW (or whatever) environment

that Makefile ends up referring to POSIX tool clones

Where communities thrive

People

Repo info

Activity