Hi Brad,
> Q: Do you like the general idea?
Yup, I think it is something we need to make writing modules that wrap
libraries much easier to use.
> 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");
}
...
}
Q: Which of the three "and/or" options above are you in favor of? (choose
0-3, though 0 is problematic without a counterproposal, I think)
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.
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.
-Kyle
On 2/11/15, 11:23 PM, "Brad Chamberlain" <[email protected]> wrote:
>
>Hi Chapel Developers --
>
>I want to float an idea that's been proposed for quite some time, but
>which I've only started to prototype tonight. The motivation is that you
>are a user or developer writing a wrapper for some external library, so
>you create a Chapel module, Foo, that wraps its externed routines.
>
>However, at present, for a user to make use of such a module, they'd also
>need to list the .h, .c, .o, .a files on the 'chpl' command-line in order
>for the compiler to know what headers to include and what to link
>against.
>This puts an unfortunate burden on the user.
>
>So, the proposal is to permit library developers to specify these
>dependences within the module itself. This could be done using new
>syntax/keywords (in which case, we'd need a proposal), or by extending
>the
>'use' keyword to take string literals that would be treated similarly to
>how they would be if listed on the command-line.
>
>I've partially prototyped this capability tonight by adding support for
>'use'-ing .h, .c, and .o files from within a module (available in a very
>rough draft form on my use-other-stuff branch for anyone that wants to
>take a look). I've used the 'use' keyword for this purpose for now, both
>for simplicity and because it didn't require any parser changes (!).
>
>Pieces that are missing, and required for the capability to be useful, I
>think, are some combination of:
>
> 1) support for expanding shell variables in such strings
>and/or
> 2) support for specifying "-I", "-L", "-l" variants of such
> strings
>and/or
> 3) support for specifying ".a" and/or ".so" files in such strings
>
>
>Before going much further, I wanted to check in and get commentary,
>though:
>
>Q: Do you like the general idea?
>
>If so...
>
>Q: Do you prefer overloading 'use' or some other syntax? (must propose an
> alternative, if that's your choice)
>
>Q: Which of the three "and/or" options above are you in favor of? (choose
> 0-3, though 0 is problematic without a counterproposal, I think)
>
>If not...
>
>Q: Why not?
>
>
>Thanks,
>-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
------------------------------------------------------------------------------
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
