Basic support for FFI-relevant code

[gian]

I have a modest proposal. We have a reasonable number of projects now that rely on some kind of FFI code (usually C) in order to build end-user applications. This makes figuring out how to build applications reasonably complicated. I propose that we add another smackage command that interrogates a package (possibly just running another 'make' target) in order to compute the appropriate command line/CM options. We need not do anything clever in the realm of attempting to discover platform-specific weirdness (although this might be a nice v2 feature). An example usage might be:

(in my end-user Makefile):

foo: bla.mlb bla.sml
        mlton $(exec smackage linkopts curlsml v1) -output foo bla.mlb

Where smackage linkopts curlsml v1 is going to expand to something like:

-linkopt -lcurl $SMACKAGE_HOME/lib/curlsml/v1/curlsml.a

I can see some potential risks in platform-specific support being required, and we might have to think carefully about how one generates things appropriately for the chosen compiler/platform.

Any thoughts?

[robsimmons]

How good are we doing at system detection in the moment? I'm generally unopposed, but it's worth noting that this would finally make platform sections semantically meaningful.

I like this proposal because it's in line with the goals of Smackage v1: we're helping people get code onto their systems, and resolving transitive I-need-code dependencies, but it's not requiring us to solve transitive I-need-things-built dependencies.

I dislike it because it seems mlton-specific and, less importantly, seems like it will be impossible to make work on windows (everything is impossible to make work on Windows...). Thoughts? Is that an off-base assessment?

[gian]

We're bad at doing system detection right now, but I believe almost all the compilers provide some mechanism for platform detection, so I was considering writing a cross-platform library which basically just interrogates platform information, which we can then use in smackage.

The mlton-specificity is a valid point, although SML/NJ and Poly/ML require some similar contortions, so it'll be mostly up to package authors to return the information required to compile their package with all of the compilers it supports. This is analogous to things like the SDL-helper program that generates a gcc command line appropriate for linking against SDL.

I'm not sure why it shouldn't work on Windows. We're merely providing a standard interface by which package authors can signal non-SML dependencies in a way that is ready to pass to the compiler. Any Windows system with 'make' is still going to support passing command-line arguments to your chosen SML compiler, right?

[robsimmons]

Re:windows, ok.

Here there's an issue with the fact that we're not actually supporting "install".

What you'd like is that smackage instal bar has some platform-detection stuff that it does, and it knows that the dependent smackage linkopts foo will see the same platform-detection stuff. But instead, we have smackage make bar smlnj, which might call smackage linkopts foo and need some smlnj-specific stuff, and smackage make bar mlton, which might call smackage linkopts foo and need some mlton-specific stuff. But how do those two calls to smackage linkopts foo know which specific stuff to return?

[gian]

In the simplest scheme imaginable, there's a makefile target in the foo package that (when present) returns the correct linkopts for linking against foo.

In a more complex scheme, a project declares (perhaps in the smackspec) a list of non-SML artifacts that are generated by 'make', and then we have a standard way of combining these different elements into an appropriate command line for a particular platform.

[robsimmons]

The simple solution implements your modest proposal without extra smackage
features, right? And the complex proposal sounds just fine in principle,
but...

In general, I see no problem implementing experimental commands (that are
clearly marked as such) which we reserve the right to remove at a later
date without bumping the major version, if you want to play around with
some of these proposals.
On Nov 14, 2011 4:37 PM, "Gian Perrone" <
reply@reply.github.com>
wrote:

In the simplest scheme imaginable, there's a makefile target in the foo
package that (when present) returns the correct linkopts for linking
against foo.

In a more complex scheme, a project declares (perhaps in the smackspec) a
list of non-SML artifacts that are generated by 'make', and then we have a
standard way of combining these different elements into an appropriate
command line for a particular platform.

---

Reply to this email directly or view it on GitHub:
#13 (comment)