This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: [ITP] cygport
On 5/5/06, Yaakov S (Cygwin Ports) wrote:
I'm not sure why /usr/share/cygport is less misplaced than
/usr/lib/cygport/lib, except that the former sounds more accessible than
the latter. Either way, cygport still needs to be documented, then it
shouldn't really matter where the components are actually installed.
Conceded. I'll confess that my opinion was partly inspired by the
Portage code layout, and partly by an attempt to respect the FHS
(something seems a little off about having files expected to be
hand-edited by a user in a lib-path--a share-path or etc-path seemed
better to me).
Regarding further modularization, remember that for every script
executed, you have another bash process running or you need to inherit a
cygclass; therefore, the most common tasks are in cygport itself, to
avoid excessive inherit commands or runtime overhead.
Apologies, I forgot to say that I meant for those files to be
*sourced*. That way, it would work exactly the same way as it is now
(no new bash processes on invocation), but the code would be more
neatly organized.
And there are certain things that _cannot_ be modularized, e.g. insinto,
which exports a variable needed by doins, can't be separate because
AFAIK you can only export variables to child processes and not to the
parent/sibling processes.
Ah, but the source is mightier than the fork (as per above)! ;-)
In the end, nothing is finalized, and cygport should be flexible enough
to move certain things into or out of /usr/lib/cygport/bin without
changing API.
Ergo the friendly, minor suggestions (I'm writing cygport scripts this
weekend if I have time).
Yaakov
Jason