Eric Anholt <[email protected]> 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
signature.asc
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
