On Fri, Jul 14, 2017 at 04:41:44PM -0700, Bryce Harrington wrote:
With the cmake and git conversions complete, and autotools and bzr bits removed, I am wondering if there's some additional cleanup of stuff accumulated in our repository's root directory. But much of this I'm not 100% sure about (and that maybe why others haven't already dealt with it).
- distro
- libgc.supp
- tools-version.sh
I think these may be obsolete. They've been in the codebase forever, but I don't know what they are used for anymore. I'm guessing they're autotools leftovers; can we drop them?
I've gone ahead and dropped them. If anyone identifies build breakages due to these missing, please go ahead and restore what's needed, and then let me know.
- Doxyfile
This doxygen config file works fine (just ran it). However according to http://wiki.inkscape.org/wiki/index.php/Doxygen_documentation we aren't posting doxygen pages online any more.
In any case, doxygen lets you pass the config file name on its command line, so no reason this has to live in the root directory. Unless anyone has strong feelings otherwise I propose moving this file to doc/ with our other code/architecture docs. Or... other ideas?
Actually now that we have buildtools/, that is probably a better suited location with this. Building the code docs is very analogous to running CI or other build/test tools.
- inkscape.spec.in
This is an old RPM build file I made way way back. I'm sure Fedora has something better, and besides this is _completely_ out of date. I will be deleting it.
Deleted.
- inkscape.desktop.in
- inkscape.desktop.template
Is inkscape.desktop.in generated from inkscape.desktop.template? Do we need both files?
Still unsure here, leaving them for now.
- mingwenv.bat
- mingwenv.cmake
- msys2checkdeps.py
- msys2installdeps.sh
- msysenv.sh
- inkscape.appdata.xml.in
- Info.plist.in
- appveyor.sh
- appveyor.yml
- .gitlab-ci.yml
- .snapcraft.yaml
- packaging/
I know a lot of tools expect config files in the project's root directory, but can any of these be moved to packaging/? (Or maybe a utils/ dir?)
Several of these have description snippets that are essentially the first few paragraphs of the README. If the README is revised (see below), it may be worthwhile to resync the text in these from that.
Thanks for creating buildtools/ and moving a few items, hopefully we can continue migrating build related utility stuff into there.
- INSTALL
The installation directions here are for autotools so the whole file is obsolete. I only hesistate to delete it because I believe `make distcheck` requires it.
So question here is should we move the installation directions currently in the README.md file to INSTALL?
This is done.
- README.md
- README.ca.txt
- README.de.txt
- README.es.txt
- README.fr.txt
- README.it.txt
- README.pt_BR.txt
- README.sk.txt
- README.sr.txt
Speaking of the README, we've had these translations of the README for a long, long time. Most have not been updated to reflect the autotools -> cmake move, some haven't been updated in a decade. None have followed the main README's reformatting to markdown. But I wonder if translations of the README are that necessary? If not, would anyone be troubled if we dropped them at this point? Aside from the installation directions (which are out of date anyway, and maybe should move to INSTALL), the information in the README is just introductory stuff that exists in translated form on our website and elsewhere.
Dropped.
The first section of the README we have used far and wide all over the place. It's a stock text we cut and paste into anything that needs a description of our project. But it's been pointed out to me that this doesn't really reflect the current state of Inkscape and all the stuff that's been achieved since it was written. So, we may want to consider revising this. Does anyone know of a more current description of Inkscape that we could leverage for this?
- fix-roff-punct
- utf8-to-roff
These perl scripts were used to fix up punctuation goofs by pod2man. If we moved away from POD, then these are entirely superfluous and can be dropped.
The first script got moved to man/, I've done the second as well.
(I still suspect we could just drop them...)
- ChangeLog
With the newest entry in this file being from 2014, this looks vestigal. I think it used to be needed for packaging, and I think it dates to pre-bzr.
Anyone know if there's a reason to keep it?
Dropped.
Bryce