Hi Kyle --
Thanks for the notes.
>> Q: Do you prefer overloading 'use' or some other syntax? (must propose
>> an alternative, if that's your choice)
>
> I'd prefer to not overload use to mean very different things depending on
> what is in the string. I think it would also prevent us from giving very
> helpful error messages at times. What really like to do is place
> attributes onto modules or functions indicating what resource it requires,
> but in the meantime:
>
> module Regexp {
> requires {
> lib("re2"); // switched based off of --static/--dynamic perhaps? or
> just default to dynamic
> lib("bonus1", "static");
> lib("bonus2", "dynamic");
> // These three are all specific to the C back end
> include("re2.h", "<stdlib.h>");
> // I dislike these two even more as they lock us into the C backend
> compile("extra.cpp");
> link("extra2.o");
> }
>
> ...
> }
I think 'requires' is a pretty good keyword in place of where I'm
currently overloading 'use' (which I feel so-so about, at best).
To my tastes, the rest of it feels unnecessarily verbose. By analogy, I
like that the 'chpl' command line permits one to write:
chpl foo.chpl bar.h bar.c baz.h baz.o
rather than requiring:
chpl foo.chpl --include "bar.h baz.h" --compile "bar.c" --link "baz.o"
(and, in fact, I've implemented my use-based prototype by calling the same
routines that handle the command-line arguments in my current
implementation which is what made it so easy). To that end, I'd prefer:
requires "bar.h", "bar.c", "baz.h", "baz.o";
over the more verbose/explicit form you sketch above. I don't have a good
story for the static/dynamic library case, though, apart from writing
"libfoo.a", "libbar.so", and/or "-lbaz" (where I agree with you, this
latter may either suggest following --static/--dynamic or defaulting to
dynamic).
W.r.t. your concern about locking into the C back-end... I don't think
that's the case. Whatever the back-end is, one could specify that there
are additional .c/.o/... files that need to be linked into the binary to
make it work. For example, it seems the current LLVM back-end supports
additional files like this on the command-line. Similarly, I could
imagine supporting the ability to specify Fortran files to implement an
interface if we had interoperability with Fortran (I think some have
postulated that we probably already do for simple cases...?). I don't
think it locks us into any specific Chapel compiler back-end so much as it
suggests that we're willing to invoke some compiler/tool on behalf of the
user in building their binary.
It may be that a given implementation of the Chapel compiler, or given
back-end, may not be willing/able to handle a particular type of
requirement, but I think that's arguably a fragility in the library
implementation itself rather than in the feature that we're discussing
here.
(Note that, if anything, the ".h" case locks us into C as a back-end
language more than the others, since it effectively says "Add a #include
for this .h file to the generated Chapel code". I'm realizing that I'm
actually not sure what the LLVM back-end does with this case... maybe
clangs it? Or maybe just drops it on the floor?)
In the short-term, I think it's more important for us to support
interoperating with libraries in a way that doesn't require users to
specify additional dependences on the command-line rather than to worry
overmuch about forward portability of those libraries...
> 1. Not a fan of shell variables at all, and I think they have no place in
> being there.
>
> 2. I don't think -I and -L should be be specified inside of Chapel code.
> They represent search paths that can not be known on a users machine. -l
> is handled with a lib() directive in the example above.
>
As the implementer, I'd be happy not to worry about either of these cases.
:)
To be clear, though are you counterproposing that the user would be
responsible for setting up things like LIBRARY_PATH and
CPATH/C_INCLUDE_PATH in their environment to satisfy external dependences
that libraries have on specific files? (assuming the files were not in
the standard system locations?)
I was thinking that that would be more onerous than what I was proposing,
but now I'm thinking it's not so different. Specifically, the example
I've been using as motivation is that, to compile FFTW programs today,
these are the extra compiler options that a user has to pass to 'chpl':
fftw3.h -I$FFTW_DIR/include -L$FFTW_DIR/lib -lfftw3
So I'd been thinking "How can the author of FFTW.chpl make it as trivial
as possible for a Chapel user to compile against it?" where my answer was
going to be something like:
use "ffw3.h", "-I$FFTW_DIR/include" "-L$FFTW_DIR/lib" "-lfftw3";
but in retrospect, this still requires the user to set something in their
environment (FFTW_DIR rather than LIBRARY_PATH/CPATH), so maybe it's
morally no better and yours has the benefit of being simpler to implement.
The only slight downside is setting two env. vars. rather than one, in the
case that a non-system version of the library is going to be used. But
the simplicity seems worth that.
In which case, maybe the above simply becomes:
requires "fftw3.h", "-lfftw3"
or:
requires "fftw3.h", "libfftw3.a"
or:
requires "fftw3.h", "libfftw3.so"
depending on where we land on the static/dynamic/library question...
> 3. Handled w/ "static" vs "dynamic" in the example. Different platforms
> have different extensions (which might not practically matter for us..)
> but I still think we should avoid mentioning the exact file extension for
> libraries.
Are there cases other than Microsoft's .lib/.dll that you're thinking of?
Thanks Kyle,
-Brad
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
