[rfk-dev] folding in NKIs from the inform edition

[Peter A. H. Peterson]

Quoting Eric S. Raymond:
> Peter A. H. Peterson <pedro at tastytronic.net>:
> > Quoting Eric S. Raymond:
> > > I have a slightly different concern.  I would like the ports to be 
> > > refactored so there is just one NKI file in the distribution that all
> > > of them use.  In some cases this might involve writing machinery to
> > > massage it into native string-array initializers.
> > 
> > I have a slightly different concern relating to your concern. 
> > 
> > Are you proposing to create a Grand Unified Source Tree of all the
> > "ports"?  With a build system to "build" any/all of the ports from the
> > single tree?
> 
> Not necessarily  of all the ports, but of all the ports that opt in by 
> joining their histories to the repo.  Presently that's just the palmos 
> and inform ports.  I do think it would be good if more ports joined the
> master repo, but obviously that choice is up to the port maintainers.
> 
> I also don't have any particular issue with each port directory having its
> own build recipe.  I do want to get to where all the in-tree build recipes
> use the same master NKI file.  Otherwise we could have port maintainers
> doing good work on adding and fixing NKIs that doesn't get shared across
> the in-tree ports, which I think would be regrettable.

I do like the idea of all willing/able ports sharing a single source
NKI file. I think the status quo will (continue to) lead to ports with
out of date NKI lists.

Is there a way that a file could be in multiple repositories in a sensible
way? I'm thinking maybe with links or with nested repos or something? 

Or, the build process for all ports (including POSIX) could include
the NKIs as a dependency (e.g., the build script could pull the
current one from the website for that matter). Perhaps in this world
the NKI list(s) themselves would have their own repo.

As a somewhat orthogonal question, if we had a hypothetical git repo of
*all* ports, is there a way that someone could clone just the port
they are interested in? That (and my phobia of a unified build system)
is my main aversion to a unified tree.

My main concern in all of this is keeping the maintenance load low,
future-proofing whatever we decide to do, and keeping it easy for
people to develop new ports.

Thoughts?

-pedro

FYI -- My workload is heavy right now, so my responses may be a bit
slower for a while.

-- 
Peter A. H. Peterson
Graduate Student Researcher
Laboratory for Advanced Systems Research
University of California, Los Angeles