<jhass>
and I think /usr/lib/ for such stuff is much much more common across distributions than you make it sound
<waj>
it is common, of course
<waj>
on the other hand I don't think it's that bad to put all the crystal stuff in a single place
<jhass>
and whether we call libs/ stdlib or packages or libraries or whatever and whether we call src/ core or stdlib or whatever doesn't really matter. It doesn't matter which of these is shipped with crystal either. I'm asking for standard locations to put these
<jhass>
/usr/lib/crystal/ is pretty much a single place
<asterite>
If you download a random app from the internet, where do you put it?
<waj>
but /usr/lib is for libs!
CraigBuchek has joined #crystal-lang
<jhass>
why is src/ and libs/ not libraries?
<asterite>
src and lib could even not exist, they could be embedded in crystal's executable
<jhass>
I just find it ridiculous to have to ship a wrapper script
<jhass>
after all crystals aim is to produce standalone executables
<jhass>
having to set $CRYSTAL_PATH the moment you want to use a library if you could just install it to a standard location seems cumbersome
<asterite>
The thing is, we spent many weeks trying to make packages that work well in many distributions
<asterite>
Now we want to do more important things, like a package manager and a documentation generator
<asterite>
We don't find it that troublesome that everything is located in a single place
<jhass>
whether it's /usr/lib/crystal, /usr/share/crystal or even /opt/crystal I actually don't care too much, I just highly prefer /usr/lib/crystal as it makes the most sense to me
<jhass>
I'm not asking to change your packages
<asterite>
But crystal is not a library, it's a program
<jhass>
exactly
<jhass>
thus I'd prefer it to put into /usr/bin/
<jhass>
since that's where programs go
<jhass>
I can't since I have to set $CRYSTAL_PATH
<jhass>
since there's no standard for it
<asterite>
crystal exe is in /usr/local/bin/crystal
<asterite>
Maybe you can change it to make it install everything in the correct place and send us a pull request :)
<asterite>
We can assure you it will not be an easy task
<jhass>
Sorry, but again: I'm not asking to change your packages
<jhass>
I want a standard value for $CRYSTAL_PATH that crystal fallsback to if the environment variable is not set
<asterite>
Why wouldn't it be set?
<jhass>
because I'd like to use no wrapper script
<jhass>
ideally that standard value would be a compile time flag baked into the crystal executable
<jhass>
whether you have a default for that flag or not I don't care as much, though I'd still find it nice
<waj>
if the sources were on a standard location then it wouldn't be possible to untar crystal on a custom directory and run from it
<waj>
actually… the idea was this:
<waj>
for this package that is not targeted for a specific distribution, use the shell wrapper and set the CRYSTAL_PATH
<jhass>
why not? the package could set the standard value to relative paths
<waj>
but… if you want to make a custom package for a distro… then the CRYSTAL_PATH could be somehow hardcoded when you compile crystal
<jhass>
you basically already ship a standard value for $CRYSTAL_PATH by shipping the wrapper scripts (I think I saw 3 different ones by now?)
<jhass>
I'm just asking to move the place where that standard value is defined into the binary
<waj>
maybe… I just didn't want to hardcode anything now
<waj>
btw… in mac it would be different
<asterite>
Yes, I was thinking the same thing
<jhass>
what about an optional compile time flag to bake a standard value into the binary?
<asterite>
We use homebrew, we can't hardcode the path in the executable so we have to use a wrapper
<jhass>
if not set, keep it like now, you have to set $CRYSTAL_PATH
<waj>
sure… or use the environment variable present at the moment of compilation
<jhass>
if set $CRYSTAL_PATH overwrites it
<waj>
yes, that's the idea… eventually
<jhass>
but don't use the value of $CRYSTAL_PATH at compilation time
<jhass>
that's different already in order to be able to compile
<waj>
yup, true
<jhass>
I guess it's time for gcc -D style things or just make a ./configure like script that writes some .cr or config file
<waj>
however… I don't agree we have to make the generic package install in system shared directories. I'd left that to customized packages for each distro.
<asterite>
You can do something like this: crystal_path = {{ env("CRYSTAL_PATH") || "src:libs" }}
<jhass>
I think I never said that. At least I didn't want to, sorry if it sounded like that
<asterite>
That would set crystal_path to ENV["CRYSTAL_PATH"] at compile time, or "src:libs" if its not set
<jhass>
another thing I noticed while writing the new arch package is that version.cr depends on a git checkout
<waj>
oh… my bad then, no need to be sorry
<waj>
yup, we want to change that too
<waj>
at least have the option to get the version from somewere else
<jhass>
yeah, currently I parse it out of version_manifest.txt and sed version.cr
<waj>
mm… I removed the version_manifest.txt from the latest package :)
<jhass>
I guess what would be nice would be to extend the standalone .tar.gz with a Makefile to build a dynamically linked crystal from it
<jhass>
then the src/ could just ship a version.cr with a hardcoded version or read it from a VERSION file or something
<asterite>
It could use the value of the CRYSTAL_VERSION env variable if it's set, or use the git tag… what do you think?
<jhass>
then you should remove the [sha] from the version
<jhass>
I'm think I'm not to keen on compile time configuration over environment variables, for example for the standard crystal path, you already have CRYSTAL_PATH for the compiler run then something like STANDARD_CRYSTAL_PATH for the default value
<asterite>
So you'd like a configuration script?
<jhass>
I think so, yeah
<jhass>
Have a look at RbConfig::CONFIG in ruby for example, it defines all the compile time settings
<waj>
btw… please check your sha256's
<waj>
because I replaced the packages I originally published
<jhass>
mmh
<waj>
I should had set -2 to the files instead… but I didn't want to start with a broken package :)
<waj>
sorry about that… I didn't expect someone would catch up so quickly
<waj>
and I promise it would not happen again ;)
<jhass>
:)
<waj>
and again… the version-manifest.txt is not there anymore...
<waj>
do you really need it?
<jhass>
well, otherwise I have to hardcode the sha into the package or make one up
<jhass>
this is just because version.cr depends on a git checkout currently
<asterite>
What would a ./configure script do?
<waj>
oh… to put the hash between brackets…
<jhass>
default for crystal path, probably version number, if you ever provide a make install prefix for that
<jhass>
you do library path detection in the compiler currently so that part fails out
<jhass>
*falls
<asterite>
But how do we pass those values to the compiler? The only way to communicate these things at compile time is with env variables
<asterite>
We have ifdef flags, but those are always booleans
<jhass>
I could imagine writing a config.cr
<jhass>
that is loaded by the compiler if it exists
<jhass>
maybe a less generic name
<asterite>
We can't check yet if a file exists at compile time, but it's doable
<asterite>
I don't think using environment variables is that ugly, really...
<asterite>
We just document it and that's it, then you pass them when you compile
<waj>
in one of our internal discussions we were thinking about having compiler flags to override the @link attributes somehow
<jhass>
asterite: maybe collect them under a standard prefix at least, CRYSTAL_CONFIG_ or something like that
<asterite>
Yes, that would be convenient
<asterite>
In Rust they use environment variables, but they don't have default values and the build fails if they are not set
<asterite>
(but I think they do have a huge build script)
<jhass>
crystal -v
<jhass>
Crystal 0.5.0 [release] (Tue Sep 30 19:08:24 UTC 2014)
<jhass>
I guess that works for now :)
<asterite>
Then we can have a Crystal::Config class where all those variables are read at compile time, and they are nil if they are not defined… and there's no need to document anything externally
<waj>
actually… if the version is tagged, it might make little sense to put the git hash there
<waj>
and considering we never, NEVER move the tags… :P
<asterite>
Then we use that in crystal/version.cr and crystal/crystal_path.cr
<jhass>
asterite: yeah, sounds good :)
<asterite>
If you want to make those changes please make a pull request (because maybe you have that and other things in mind)
<asterite>
If those changes help you make your arch linux package easier to build, lets go for it
<jhass>
I think I mostly just find that a lot cleaner
<jhass>
btw. 0.5.0 doesn't seem to be able to compile master?
<jhass>
ah, no I think I know what's going on
<jhass>
bin/crystal needs to set CRYSTAL_PATH :P
<asterite>
Indeed
<asterite>
But we changed bin/crystal to use the crystal installed in your system, which should be the wrapper script that sets the path
<asterite>
But, yes, once we change that crystal_path issue, things will be smoother
<asterite>
(although I'm not sure we will remove the wrapper, at least in the way we distribute things)
<jhass>
what does CRYSTAL_BIN do?
<asterite>
If you set it, the wrapper uses that path instead of crystal
<asterite>
That way when you compile a compiler and it's left in .build/crystal, when you invoke it through bin/crystal it will set the correct environment variables and then invoke .build/crystal
<asterite>
It's a small hack, but that way the specs can find all the static libraries that come with crystal (like gc and pcre)
<asterite>
In that way you don't need to have those installed in your system…
<jhass>
so bin/crystal depends on the statically linked packages for system installed versions
<asterite>
It's so the executables created with crystal have gc, pcre and some others statically linked in them, so you can copy them to another machine and they should work
<jhass>
you'll never get into debians official repos if you force statically compiled stuff :P
<asterite>
We don't want to get into debians official repos :)
<jhass>
never?
<asterite>
We had dinamically linked libraries and they didn't work on arch linux, for instance
<waj>
the problem is… for example the distributed version of libgc is quite old
<asterite>
Eventually yes
<asterite>
Maybe when we reach 1.0
<jhass>
It totally makes sense to distribute "bootstrap" versions that are statically compiled
<jhass>
I'm not sure if it should be the main paradigm
<jhass>
in the long term
<waj>
I agree… but official repositories tend to become outdated very quickly
<waj>
for example, with ruby in precise the latest version was 1.9.3
<jhass>
yeah, not saying it's wrong in the current development phase
<jhass>
just maybe take some care to not depend too much on it
<waj>
so everybody would use rvm, rbenv or whatever method to install a custom version
<waj>
yup, sure
<waj>
at this stage… we just want anyone can download and try crystal
<jhass>
like in my dynamically linked package i have to support the CRYSTAL_BIN hack now while it makes no sense there
<waj>
anyone = anyone with mac or linux ;)
asterite1 has joined #crystal-lang
mverzilli has joined #crystal-lang
<asterite1>
.deb and .rpm don't work in arch linux?
<jhass>
I'm don't follow?
<jhass>
I could make a package that extracts and repackages those sure, but there's already the tar.gz to do that in case I wanted to package a statically linked version
<asterite1>
I mean, what's a standard package in arch linux?
<asterite1>
We could provide that in addition to .deb and .rpm
<asterite1>
and it would be integrated in omniauth-crystal so you wouldn't have to maintain the aur package separately
<jhass>
pacman is the package manager, by default the packages are .tar.xz that follow a special format created by makepkg
<jhass>
and it's not all that complicated to maintain a package, that's why the AUR has so many of them ;)
<waj>
yup… that's really great. Debian packages is a real PITA
<asterite1>
That 0.5.0 package already works?
<jhass>
asterite1: yes
<asterite1>
Wow
<jhass>
well, that version is broken, let me upload the fixed one for your reuploads ;)
<asterite1>
But it still has the wrapper and other things you don't like, right?
<jhass>
just the wrapper and the version sed
<jhass>
I'd like to drop those
<jhass>
so no problem to make the build() function make release=1 CRYSTAL_CONFIG_PATH="/usr/lib/crystal/src:/usr/lib/crystal/libs"
<jhass>
;)
<asterite1>
Good, later I'll make that Config module (unless you want to do it… I'm asking because since you are that package maintainer you definitely know better than us what needs to be changed :)
<asterite1>
There's still the problem with sha and build date… maybe we can use CRYSTAL_CONFIG_VERSION if it's set, and it must include the full version string (with sha and build date)
<asterite1>
Or just with sha and the build date is computed at compile time
<asterite1>
What do you think?
<jhass>
I think build date at compile time is best, like it's now
<jhass>
I'm not sure what you need the sha for tbh