this is a tricky one. we had a symbolic link before but that resulted in people checking in the binary of jruby-launcher as jruby.bash to git. and on some platform it did not work.

copying it over on each run is obey the update but will make the jruby-launcher install useless.

maybe copy it on a clean build is doable compromise. not sure how important the jruby-launcher when working on jruby itself. IMO updated bin/jruby is more important then binary launcher.

Is the concern that you'll be modifying jruby.bash on a local working copy and it won't get updated to bin/jruby? If so, how often are we doing that?

FWIW, we have some folks helping us rewrite the native launcher using mruby, so things may change up a bit when that works.

This has bit a few people already. Granted it's all been on the Truffle side, but since the launcher essentially works, just with outdated config, it's extremely annoying to track down. I would have expected whatever profile (bootstrap?) that generates the file in the first place would just regenerate it all the time.

@nirvdrum are you saying -Pbootstrap just shall reinstall the jruby-launcher any time it gets executed ?

@mkristian I'm not sure of what the exact sequence is here, so please forgive me if I get some of the details wrong. What I'm saying is bin/jruby isn't committed to the source tree, so it must be generated somehow. I'd expect whatever phase or profile responsible for its initial generation to also handle regeneration. Whether that's done on every invocation of something smarter can be done with file mtime, I'm not sure.

@nirvdrum there are two things happening:

• if there is no bin/jruby then it will be copy bin/jruby.bash to bin/jruby
• whenever you run -Pbootstrap that will install the jruby-launcher gem which does replace bin/jruby

what is creating the problem with "truffle" the copied bash script or the binary from the jruby-launcher gem ?

I couldn't get -Pbootstrap to copy the bash script back over bin/jruby . . . I had to do it manually. Maybe I just messed up, but it didn't seem to be working. The problem with Truffle is we've updated the bash script, but anyone that has already checked out the JRuby source tree will end up running with the old bash script (previously copied to bin/jruby). Newer versions of Truffle need to be on the bootclasspath, not the classpath. Running with the old bash script means you don't pick up the new JVM options and get a very obtuse error message.

the bin/jruby gets not touched once it is there. would a mvn clean resetting thing help ? just try to help to find a solution which does not slow down the actual building of lib/jruby.jar

Maybe I'm just confused, but if -Pbootstrap doesn't currently overwrite the file if it exists, can we make it do so? I don't think that profile is run very often. It's not ideal, since someone would still need to know to run it, but it's better than silently doing nothing.

@headius Is the concern that you'll be modifying jruby.bash on a local working copy and it won't get updated to bin/jruby? If so, how often are we doing that?

Yes, just to print out the actual java command for instance. And bash is more easy to hack than a bunch of C++ 😃

@mkristian Yes, if mvn clean would remove it, it would already fix the case that you have an outdated (bash) bin/jruby older than bin/jruby.bash, even after full clean + build, which is the confusing part.
An alternative would be if mtime(jruby.bash) > mtime(jruby), cp jruby.bash jruby, which would be intuitive in a make-like build system.

I am not using jruby-launcher most of the time for dev, but I think a full mvn clean + mvn build should produce the exact same result as if the repo was just checked out, and so the launcher binary should be replaced or at least in the case that jruby.bash is newer.

I just saw that the jruby-launcher gets ONLY installed on release versions.

for me it is just OK to copy over the bin/jruby.bash on every mvn install or mvn from the root directory. or the otherway around: to install the jruby launcher makes no sense on the git tree since bin/jruby will be deleted on mvn clean

I think for dev in the git tree it makes sense to not require jruby-launcher, and also ensures the bash version still works.
Having it copied over on normal mvn would be good and consistent, or at least if the jruby.bash is newer.

done with b799bff