Discussion:
[Inkscape-devel] inkscape root dir tidying thoughts
Bryce Harrington
2017-07-14 23:41:44 UTC
Permalink
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?


------------------------------------------------------------------------
+ inkscape.ico
+ inkscape.png

The share/icons/application/ directory is the formal place for our
icons, with share/branding/ the official source for branding files.

Only the windows packaging refers to inkscape.ico. So I think this
could be moved to packaging/. Or perhaps windows could be changed to
use the .png files like everything else?

Doxyfile seems to reference inkscape.png but I believe it could as
easily use one of the icons in share/icons/application/, but see
below...


------------------------------------------------------------------------
+ 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?


------------------------------------------------------------------------
+ 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.


------------------------------------------------------------------------
+ inkscape.desktop.in
+ inkscape.desktop.template

Is inkscape.desktop.in generated from inkscape.desktop.template? Do we
need both files?


------------------------------------------------------------------------
+ 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.


------------------------------------------------------------------------
+ download-gtest.sh

This still seems necessary for setting up gtest (although current trunk
breaks on configure due to lack of a "Findgtest.cmake"; but that seems
unrelated).

Having to use this script has always seemed a bit hacky to me. (and
it's downloading gtest 1.7, but 1.8 is current). I know there's been
some good work done on improving our testing cmake rules, I wonder if
there is a way we can eliminate this script?


------------------------------------------------------------------------
+ testfiles/

Speaking of tests... Is there a reason why we call this directory
testfiles/ rather than a more traditional name like 'test/' or 'tests/'?


------------------------------------------------------------------------
+ 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?


------------------------------------------------------------------------
+ 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 so

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?


------------------------------------------------------------------------
+ inkscape.pod
+ inkscape.de.pod
+ inkscape.el.pod
+ inkscape.fr.pod
+ inkscape.ja.pod
+ inkscape.sk.pod
+ inkscape.zh_TW.pod
+ inkview.1.in
+ man/

Unlike the README's, the translated man pages have been getting updates.
The --no-convert-text-baseline-spacing option is only documented in the
English inkscape.pod, but the previously added option,
--export-ps-level, (from 2013) is present in all.

However, these should move down into the man directory. The CMake code
is already in CMakeLists.txt to generate the .pod files from the man/
directory, so recent changes to the root *.pod's just need to be sync'd
with the corresponding files in man/ and then removed.

As an aside, I know we eliminated Perl from the build system, but it's
still used for the man page generation (the 'p' in pod stands for perl).
I like the POD format, but raw man page syntax (TROFF) isn't *that*
complicated; if we wanted, we could just keep all the man pages as
troff, eliminate pod usage, and simplify our build requirements.
(Compare inkview.1.in with man/inkview.pod.in to see the difference).
Would anyone be opposed (or favorable) to this change?


------------------------------------------------------------------------
+ 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.


--------------
+ COPYING
+ GPL2.txt
+ GPL3.txt
+ LGPL2.1.txt

Next, licenses...

As detailed in the COPYING file, the only reason we have GPL3.txt is
because there's a few files in our tree copied from GIMP.

Could someone please take the task of eliminating those files, so
Inkscape can return to being pure GPL2?

The LGPL2.1 isn't a problem, but according to COPYING it's only there
due to some libs we copied into the tree (I see libavoid is LGPL, is
there anything else?) If the LGPL libs were changed to be external
dependencies instead of copied into src, we could eliminate the
LGPL2.1.txt file too.


------------------------------------------------------------------------
+ CMakeLists.txt
+ CMakeScripts/
+ cmake_uninstall.cmake.in
+ config.h.cmake

CMake is nice and concise compared to autotools. I do wonder if
cmake_uninstall.cmake.in could perhaps be moved into CMakeScripts/. If
anyone else wants to move it, please do, else I'll look into it some
time.


------------------------------------------------------------------------
+ astylerc

This config file appears to be for a code formatting tool. I vaguely
remember kk discussing it a while back. Is anyone still using it?

The astyle man page indicates it supports using --options=FILENAME to
specify a path to astylerc, so the file could be moved to utils/ or
elsewhere.

I see we already have the options documented at
https://inkscape.org/en/develop/coding-style/ including directions for
how to store the settings locally in ~/.astylerc. If no one is actively
using this tool, that might be a better solution and remove astylerc
from the codebase.


------------------------------------------------------------------------
+ _clang-format

I'm not sure why this is in the tree. Guessing it was a jenkins-related
thing? I suspect we can drop this.


------------------------------------------------------------------------
+ setup/

This appears to be current, but what is it? It has a single subdir with
a single file, which looks like a copy of inkscape.desktop.in with
translations embedded. Why is this in a directory called 'setup'?


------------------------------------------------------------------------
+ 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?


------------------------------------------------------------------------
+ AUTHORS
+ TRANSLATORS
+ NEWS
+ doc/
+ share/
+ src/
+ po/

This is all pretty stock, no comment here.


Bryce

P.S. if you've read to this far, thanks! This ended up way longer than
I anticipated, sorry!
Olof Bjarnason
2017-07-15 08:26:44 UTC
Permalink
Hi Bryce,

I think that is a great write-up, and improving this kind of thing
(janitor tasks like removing unused files, making root as simple as
possible) has a good effect on getting new members on board, as it
reduces the friction of learning what-is-what and in general just
simplifies the repo.

Does it make sense to put up each of those tasks on the Gitlab
tracker, possibly with a specific label "cleanup"? At least those
tasks where there are no question marks.

Those things that have question marks needs further investigation, but
come to think of it that could be put up as issues with label
"investigate" or something?



Mvh


/Olof
-----------------
Är du systemutvecklare?
Spana in https://cilamp.se
Post by Bryce Harrington
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?
------------------------------------------------------------------------
+ inkscape.ico
+ inkscape.png
The share/icons/application/ directory is the formal place for our
icons, with share/branding/ the official source for branding files.
Only the windows packaging refers to inkscape.ico. So I think this
could be moved to packaging/. Or perhaps windows could be changed to
use the .png files like everything else?
Doxyfile seems to reference inkscape.png but I believe it could as
easily use one of the icons in share/icons/application/, but see
below...
------------------------------------------------------------------------
+ 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?
------------------------------------------------------------------------
+ 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.
------------------------------------------------------------------------
+ inkscape.desktop.in
+ inkscape.desktop.template
Is inkscape.desktop.in generated from inkscape.desktop.template? Do we
need both files?
------------------------------------------------------------------------
+ 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.
------------------------------------------------------------------------
+ download-gtest.sh
This still seems necessary for setting up gtest (although current trunk
breaks on configure due to lack of a "Findgtest.cmake"; but that seems
unrelated).
Having to use this script has always seemed a bit hacky to me. (and
it's downloading gtest 1.7, but 1.8 is current). I know there's been
some good work done on improving our testing cmake rules, I wonder if
there is a way we can eliminate this script?
------------------------------------------------------------------------
+ testfiles/
Speaking of tests... Is there a reason why we call this directory
testfiles/ rather than a more traditional name like 'test/' or 'tests/'?
------------------------------------------------------------------------
+ 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?
------------------------------------------------------------------------
+ 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 so
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?
------------------------------------------------------------------------
+ inkscape.pod
+ inkscape.de.pod
+ inkscape.el.pod
+ inkscape.fr.pod
+ inkscape.ja.pod
+ inkscape.sk.pod
+ inkscape.zh_TW.pod
+ inkview.1.in
+ man/
Unlike the README's, the translated man pages have been getting updates.
The --no-convert-text-baseline-spacing option is only documented in the
English inkscape.pod, but the previously added option,
--export-ps-level, (from 2013) is present in all.
However, these should move down into the man directory. The CMake code
is already in CMakeLists.txt to generate the .pod files from the man/
directory, so recent changes to the root *.pod's just need to be sync'd
with the corresponding files in man/ and then removed.
As an aside, I know we eliminated Perl from the build system, but it's
still used for the man page generation (the 'p' in pod stands for perl).
I like the POD format, but raw man page syntax (TROFF) isn't *that*
complicated; if we wanted, we could just keep all the man pages as
troff, eliminate pod usage, and simplify our build requirements.
(Compare inkview.1.in with man/inkview.pod.in to see the difference).
Would anyone be opposed (or favorable) to this change?
------------------------------------------------------------------------
+ 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.
--------------
+ COPYING
+ GPL2.txt
+ GPL3.txt
+ LGPL2.1.txt
Next, licenses...
As detailed in the COPYING file, the only reason we have GPL3.txt is
because there's a few files in our tree copied from GIMP.
Could someone please take the task of eliminating those files, so
Inkscape can return to being pure GPL2?
The LGPL2.1 isn't a problem, but according to COPYING it's only there
due to some libs we copied into the tree (I see libavoid is LGPL, is
there anything else?) If the LGPL libs were changed to be external
dependencies instead of copied into src, we could eliminate the
LGPL2.1.txt file too.
------------------------------------------------------------------------
+ CMakeLists.txt
+ CMakeScripts/
+ cmake_uninstall.cmake.in
+ config.h.cmake
CMake is nice and concise compared to autotools. I do wonder if
cmake_uninstall.cmake.in could perhaps be moved into CMakeScripts/. If
anyone else wants to move it, please do, else I'll look into it some
time.
------------------------------------------------------------------------
+ astylerc
This config file appears to be for a code formatting tool. I vaguely
remember kk discussing it a while back. Is anyone still using it?
The astyle man page indicates it supports using --options=FILENAME to
specify a path to astylerc, so the file could be moved to utils/ or
elsewhere.
I see we already have the options documented at
https://inkscape.org/en/develop/coding-style/ including directions for
how to store the settings locally in ~/.astylerc. If no one is actively
using this tool, that might be a better solution and remove astylerc
from the codebase.
------------------------------------------------------------------------
+ _clang-format
I'm not sure why this is in the tree. Guessing it was a jenkins-related
thing? I suspect we can drop this.
------------------------------------------------------------------------
+ setup/
This appears to be current, but what is it? It has a single subdir with
a single file, which looks like a copy of inkscape.desktop.in with
translations embedded. Why is this in a directory called 'setup'?
------------------------------------------------------------------------
+ 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?
------------------------------------------------------------------------
+ AUTHORS
+ TRANSLATORS
+ NEWS
+ doc/
+ share/
+ src/
+ po/
This is all pretty stock, no comment here.
Bryce
P.S. if you've read to this far, thanks! This ended up way longer than
I anticipated, sorry!
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Bryce Harrington
2017-07-15 17:38:15 UTC
Permalink
Post by Olof Bjarnason
Hi Bryce,
I think that is a great write-up, and improving this kind of thing
(janitor tasks like removing unused files, making root as simple as
possible) has a good effect on getting new members on board, as it
reduces the friction of learning what-is-what and in general just
simplifies the repo.
Does it make sense to put up each of those tasks on the Gitlab
tracker, possibly with a specific label "cleanup"? At least those
tasks where there are no question marks.
Those things that have question marks needs further investigation, but
come to think of it that could be put up as issues with label
"investigate" or something?
Yeah, that's good thinking. Some of these items can just be done
directly if there's no objections, but others sound like they'll need
some fiddling or research, and those would make good tasks for the
tracker.

Bryce
Post by Olof Bjarnason
Mvh
/Olof
-----------------
Är du systemutvecklare?
Spana in https://cilamp.se
Post by Bryce Harrington
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?
------------------------------------------------------------------------
+ inkscape.ico
+ inkscape.png
The share/icons/application/ directory is the formal place for our
icons, with share/branding/ the official source for branding files.
Only the windows packaging refers to inkscape.ico. So I think this
could be moved to packaging/. Or perhaps windows could be changed to
use the .png files like everything else?
Doxyfile seems to reference inkscape.png but I believe it could as
easily use one of the icons in share/icons/application/, but see
below...
------------------------------------------------------------------------
+ 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?
------------------------------------------------------------------------
+ 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.
------------------------------------------------------------------------
+ inkscape.desktop.in
+ inkscape.desktop.template
Is inkscape.desktop.in generated from inkscape.desktop.template? Do we
need both files?
------------------------------------------------------------------------
+ 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.
------------------------------------------------------------------------
+ download-gtest.sh
This still seems necessary for setting up gtest (although current trunk
breaks on configure due to lack of a "Findgtest.cmake"; but that seems
unrelated).
Having to use this script has always seemed a bit hacky to me. (and
it's downloading gtest 1.7, but 1.8 is current). I know there's been
some good work done on improving our testing cmake rules, I wonder if
there is a way we can eliminate this script?
------------------------------------------------------------------------
+ testfiles/
Speaking of tests... Is there a reason why we call this directory
testfiles/ rather than a more traditional name like 'test/' or 'tests/'?
------------------------------------------------------------------------
+ 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?
------------------------------------------------------------------------
+ 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 so
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?
------------------------------------------------------------------------
+ inkscape.