Another protocol repository merge attempt
Keith Packard
keithp at keithp.com
Fri Dec 15 00:21:31 UTC 2017
Eric Anholt <eric at anholt.net> writes:
> I like that it's just commits and merges instead of filter-branch.
Yeah, it makes the history really easy to see, and (if we don't move
files), the per-file history easy to track.
> I think it would make more sense if the headers matched the structure they
> are installed into, but that could be a thing we could move later.
That's a good idea. Having the source reflect the installed tree would
be nice.
> Similarly, the Makefile.am is gross, but if it's autogenerated then it's
> also pretty believable and easy to fix up by hand later.
Yes, it's entirely autogenerated with a script (which is in the
repo). I'd suggest cleaning it up as we move files around later on.
One question I have remaining is what to do with the specs -- having
them all mashed into the 'specs' directory is pretty ugly. I guess we
can clean that up in the same manner as cleaning up the header file
locations?
Oh -- I can't build any of the specs correctly; none of the fonts are
selected right. I've fixed that in other projects by actually shipping
the fonts as a part of the documentation source and referencing them
directly from the fop configuration file. This seems kinda messy, but it
results in reliably built documentation, which is something of a
feature.
Of course, bugs in the fonts will involve copying new versions into our
repo. I don't have a great solution here. I do suspect the Oracle has
their AWT configured to find local fonts so that the docbook toolchain
works, but that isn't true for me, and relies on having the right fonts
on the build system anyways.
--
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.x.org/archives/xorg-devel/attachments/20171214/43ffe968/attachment.sig>
More information about the xorg-devel
mailing list