Unable to start a Jiffy using project

[blt]

If an application has jiffy as a dependency, rebar3 will compile the project and build a release just fine but the release will crash on startup.

I've started a project to reproduce. The corresponding issue in its tracker: blt/robot_utopia#1

[ferd]

Jiffy is an lolspeed NIF JSON library. rebar3 can't compile jiffy as it doesn't, as I understand it, bundle a makefile, relying instead on compile hooks which rebar2 supports but rebar3 does not.

Compile hooks are supported by both rebar and rebar3. Maybe I'm understanding you incorrectly?

[blt]

It was my understanding that rebar2's NIF compilation that jiffy relies on is not supported by rebar3. The shared object is not being compiled by rebar3, at the least.

[tsloughter]

Right, it is the port compiler that rebar2 has that rebar3 does not. So either jiffy needs to be forked and add a Makefile added, then use the post or pre compiler hooks (supported in both rebar2 and rebar3) to run the makefile.

Or have a more complicated Makefile at the top level that can compile jiffy's C from there.

[ferd]

Or someone writes a C-compiling pluginfor rebar3 porting rebar2's functionality.

[blt]

On the one hand, that's a thankless task that will be hard to get right and keep right. On the other, going around hat-in-hand to every NIF project is not fun.

puts hat in hand

@davisp How would you feel about a contribution to Jiffy to rig up the compilation through a Makefile and some compiler hooks to support both rebar2 and rebar3?

[tsloughter]

I think that is what it is going to take. Forking and pull requests and use your fork until the original author accepts it :)

[blt]

Fair. That's the plan next week but I don't want to get into the situation of keeping a long-lived fork alive. :)

On Mar 27, 2015, at 18:39, Tristan Sloughter notifications@github.com wrote:

I think that is what it is going to take. Forking and pull requests and use your fork until the original author accepts it :)

—
Reply to this email directly or view it on GitHub.

[tsloughter]

We could also consider creating a github org called rebar3-compatible to keep the forks, with the hopes of getting them merged back upstream.

[tsloughter]

Here is a working fork. The only issue that makes it not exactly the same on rebar3 is windows support and the gdb plugin.

Maybe @davisp would be ok with the temporary patch that makes it work with rebar3 minus this differences (keeping the parts used by rebar2 in the config so it continues to function the same).

[tsloughter]

Opened a PR to get a discussion going: davisp/jiffy#84

[davisp]

I'm a bit sad to hear that rebar3 has dropped the port compiler from rebar2 as that was one of the main reasons I started using rebar in the first place. Though I do understand the desire to remove accumulated cruft.

As to the issue at hand, @tsloughter's PR on jiffy isn't something I'm immediately thrilled about. The dependency on GNU Make is troublesome. I'm scratching my head why we'd want to add that requirement when we've already got a perfectly good port compiler.

To me, the only real solution here is to have someone port the port compiler (while drinking port?) to rebar3. If that someone has to be me then I may find time to do it. I've been meaning to look harder at rebar3 and that would be a natural place to start.

[tsloughter]

A plugin that provides the same functionality as the port compiler would be great.

[blt]

I think that's probably the smoothest way to get rebar3 to take over for rebar2. I've just gotten started here: https://github.com/blt/port_compiler

[tsloughter]

@davisp I should note that the reason we felt it right to take it out is how often it broke. If it was not seen as a piece of rebar that constantly caused headaches and was suppose to work for so many cases it became overwhelming, it would be a different story.

But a per project Makefile or whatever script to build would remove the issue of rebar changes breaking that projects compilation. We saw make as an already existing and well used tool for building C/C++.

Are there issues you see about using make besides Windows support? A very valid concern, just curious.

[davisp]

@tsloughter I guess I just have a different experience as it always Just Works ™ from my point of view. There is a bit of a wonky bit trying to detect a cygwin vs. Visual Studio tool chain on windows.

The downside to a Makefile per project is that it turns supporting multiple platforms into a per-project best effort situation. I'd personally have to maintain that cross platform build for a half dozen projects. The very first thing I'd do in that situation is write the plugin so that I'm not duplicating that work across projects.

And finally, the dependency on GNU Make is a bit worrisome. In my experience that's not something that's universally installed or it's installed as gmake which may or may not be in the default path. And its not really Make that concerns me here. Its all of the acquired knowledge around platform/compiler detection and passing the appropriate flags for compiling. Splitting all of that knowledge between all of the various repos strikes me as not an awesome approach.

[tsloughter]

We hoped to alleviate much of that missing 'knowledge' with the cmake template we provide with rebar3. It creates a Makefile in c_src that works for most cases. In the case of Jiffy I simply had to add -lstdc++ to LDFLAGS.

My experience over the years has been builds failing silently (build would complete "successfully" but no .so would exist in priv) if you didn't use the appropriate rebar. Forcing many projects with C code to have to include rebar in the repo just to be safe. That is the main issue I've experienced with it.

[tsloughter]

@blt should we close this now?

[blt]

Ah, yep! Knew I was forgetting something. :)