[rfk-dev] folding in NKIs from the inform edition
Peter A. H. Peterson
pedro at tastytronic.net
Sun Nov 4 13:27:24 PST 2012
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.
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
More information about the rfk-dev