subports * prepend?

[Eric Gallager]

If it's so easy to work around it, then that means it should be pretty easy
to add an alias or something that does the same thing as the workaround in
base, right?



On Wed, Oct 2, 2013 at 5:37 PM, Ryan Schmidt <ryandesign at macports.org>wrote:

>
> On Oct 2, 2013, at 13:53, Peter Danecek wrote:
>
> > (1)
> > I am working on a port for iRods. This software package would provides a
> server and a set of clients. Currently I am interested only in the client
> part (for those who might know the product: icommands and fuse) and there
> might be no need for the server part after all, but how knows. So I would
> like to anticipate this possibility.
> >
> > As the ports (server + 1* clients) would share substantial parts
> Portfile code (it is built from one single package), I guess it is a good
> idea to use subports for this. I have little experience with this, but I
> think one could come up with something like this:
> >
> > irods
> >       The main port itself, either meta port or server port w/
> dependency on clients?
> >       A port which is not supposed to be used directly, like is the case
> for example for the py-* ports?
> >
> > irods-server
> >       for the server part
> >
> > irods-clients
> >       all clients (use variants to switch on parts?)
> >
> > irods-icmds / irods-client-icmds / irods-icommands
> > irods-fuse / irods-client-fuse
> >       for the various clients separated into different subports
> >
> > Maybe at some point it might be helpful to separate a lib subport as
> well, but this probably depend on the project itself.
> >
> > So what are the pros/cons in doing the one o the other? Any guidelines
> for the port naming?
> >
> > How to deal with the main port if it is supposed to do nothing? Do I
> need to disable all phases or is the intended use different? Should it
> provide just a message to the user (any good example for this?). I was
> looking a bit around i the repo, but found no example which fits exactly
> the above situations.
>
> I'm not familiar with iRODS so it's hard for me to say whether you should
> have a single client (sub)port or multiple client (sub)ports.
>
> Can I assume that the FUSE, i-Commands, etc. clients are various ways of
> accessing an iRODS server? And that different users -- or even different
> programs -- might need to use different clients? If so, variants should not
> be used, since a port cannot depend on a variant of another port. So I
> would say your choices are between a single client port that installs all
> clients always (without any variant choices), or multiple client subports,
> each of which installs one client, and all of which can be installed
> simultaneously. Your choice of which route to take would be based whether
> all clients are in a single distfile, how their build system is set up, and
> how long it takes to build. If each client is its own distfile, or the
> build system is set up to build only one client at a time, or it takes a
> long time to build, those would be good reasons to use a separate subport
> for each client.
>
> If you don't need the server now, you don't need to worry about that; you
> can add a subport for it later if needed.
>
> > (2)
> > Am I correct that there are no *-prepend equivalents to *-append?
>
> That's right.
>
> > Is there a way the have this functionality? I was thinking to do
> something like:
> >
> >    long_description-perpend \
> >        This subport provides the i-commands client.
> >
> > Where the generally description of the system is given in the main port.
>
> long_description    This subport provides the i-commands client.
> ${long_description}
>
> My subports often have the same description as the main port. This is bad
> and due to laziness, and when I've thought of changing this, I've thought I
> would append, not prepend. However that may be because as you say we don't
> have a -prepend operator and I had not previously considered how easy it is
> to work around that.
>
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20131002/ebbfaa84/attachment-0001.html>