[ITP] cygport

[Jason Alonso]

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