subports * prepend?

[Ryan Schmidt]

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.