[Inkscape-devel] inkscape root dir tidying thoughts

[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!

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



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]

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

[Eduard Braun]

Hi Bryce,

thanks for looking into this! I'm all in favour of tidying the repo.
It's always hard to tell what's still needed and what can be (re)moved,
especially with Inkscape having a lot of independent developers and I
guess most people prefer to err on the safe of caution in order not to
break anything for somebody else so a lot accumulates over time...

Post by Bryce Harrington
------------------------------------------------------------------------
+ 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...

inkscape.ico is also compiled into Windows executables, so we can't drop
it. Moving to share/icons/application/ would be fine though.

Post by Bryce Harrington
------------------------------------------------------------------------
+ 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.

What about moving (most of them) to a "buildtools" folder (I guess that
describes them best)?

mingwenv.bat - still used for devlibs-builds. Seeing that devlibs-builds
are currently broken the best path is probably to completely move to
MSYS2 eventually (unless somebody plans to continue to maintain the
devlibs) which would make this file unneeded.
mingwenv.cmake - should go into CMakeScripts/ (it's used by cmake when
building on Windows)
msys2* - buildtools/ (CI relies on their location though, so has to be
adjusted by whoever does the move)
msysenv.sh - equivalent to mingwenv.bat when building from an MSYS
shell. Is/was anybody ever using that? What about Sebastian (he
introduced this file originally). Do you still need it?
appveyor.sh - / buildtools (CI relies on it's location though, so has to
be adjusted by whoever does the move)
appveyor.yml - needs to stay in root (used by AppVeyor.ci). If you
prefer to bunch everything it could be prefixed with a dot though

Post by Bryce Harrington
------------------------------------------------------------------------
+ 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?

I added support for gtest 1.8 in 6b8520e which should now be
auto-detected by cmake if installed in the system (tested on Windows,
maybe somebody on Linux with gtest 1.8 installed could cross-check).
If we're fine to require gtest >= 1.8 (it's the first to include gmock)
we can drop the script already (plus some legacy cmake code). Otherwise
we'd require some additional code.

Post by Bryce Harrington
------------------------------------------------------------------------
+ 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?

Regards,
Eduard

[Bryce Harrington]

Post by Olof Bjarnason
Hi Bryce,
thanks for looking into this! I'm all in favour of tidying the repo.
It's always hard to tell what's still needed and what can be (re)moved,
especially with Inkscape having a lot of independent developers and I guess
most people prefer to err on the safe of caution in order not to break
anything for somebody else so a lot accumulates over time...

Post by Bryce Harrington
------------------------------------------------------------------------
+ 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...

inkscape.ico is also compiled into Windows executables, so we can't drop it.
Moving to share/icons/application/ would be fine though.

Sounds good.

Post by Olof Bjarnason

Post by Bryce Harrington
------------------------------------------------------------------------
+ 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.

What about moving (most of them) to a "buildtools" folder (I guess that
describes them best)?

That would be fine with me. I almost suggested something similar myself
but worried anything 'buildfoo' might get confused with cmake's 'build'
directory. (I suggested 'utils' only because we have a similar
directory in inkscape-web for misc. tools.)

Post by Olof Bjarnason
mingwenv.bat - still used for devlibs-builds. Seeing that devlibs-builds are
currently broken the best path is probably to completely move to MSYS2
eventually (unless somebody plans to continue to maintain the devlibs) which
would make this file unneeded.

ok

Post by Olof Bjarnason
mingwenv.cmake - should go into CMakeScripts/ (it's used by cmake when
building on Windows)

That sounds good. Yes, there seems little reason not to continue
consolodating cmake items under CMakeScripts.

Post by Olof Bjarnason
msys2* - buildtools/ (CI relies on their location though, so has to be
adjusted by whoever does the move)
msysenv.sh - equivalent to mingwenv.bat when building from an MSYS shell.
Is/was anybody ever using that? What about Sebastian (he introduced this
file originally). Do you still need it?
appveyor.sh - / buildtools (CI relies on it's location though, so has to be
adjusted by whoever does the move)
appveyor.yml - needs to stay in root (used by AppVeyor.ci). If you prefer to
bunch everything it could be prefixed with a dot though

Yes, if there's stuff that simply can't be put into a subdir, but can be
named starting with a dot, do so.

Post by Olof Bjarnason

Post by Bryce Harrington
------------------------------------------------------------------------
+ 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).

-- I figured this out, just a missing dependency; the gtest warning was
just way more noticeable than the dependency error message. :-)

Post by Olof Bjarnason

Post by Bryce Harrington
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?

I added support for gtest 1.8 in 6b8520e which should now be auto-detected
by cmake if installed in the system (tested on Windows, maybe somebody on
Linux with gtest 1.8 installed could cross-check).
If we're fine to require gtest >= 1.8 (it's the first to include gmock) we
can drop the script already (plus some legacy cmake code). Otherwise we'd
require some additional code.

Yes, this definitely sounds like a situation where moving to the newer
version simplifies the build. Since we're asking users to manually
install it rather, instead of pulling it from the system, it's not an
"ordinary" dependency so legacy support isn't a question. Besides,
Inkscape 0.93 is already seeing a lot of major changes - gtk3, git,
gitlab, cmake-only... changing the gtest version requirement is pretty
minor in comparison.

Bryce

[Jabier Arraiza]

Post by Bryce Harrington
-------------------------------------------------------------------
-----
 + 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.

Is a similar objective than astylerc both need external programs to
run maybe we need to select the less intrusibe or the best OS
compatibility one

[Bryce Harrington]

Post by Jabier Arraiza

Post by Bryce Harrington
-------------------------------------------------------------------
-----
 + 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.

Is a similar objective than astylerc both need external programs to
run maybe we need to select the less intrusibe or the best OS
compatibility one

True, yes, not a bad idea. Alternatively, if we're going to have a
collection of such things, they could be housed in a subdirectory
somewhere. Projects will often carry configs for vim, emacs, and other
editors... Having them in one place might also make it easier to spot
discrepancies in each other's formatting configurations.

Bryce

[Jabier Arraiza]

Bryce I agree one configs folder. Also we can move doxigen file here.

Post by Bryce Harrington

Post by Jabier Arraiza

Post by Bryce Harrington
---------------------------------------------------------------
----
-----
 + 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.

Is a similar objective than astylerc both need external programs to
run maybe we need to select the less intrusibe or the best OS
compatibility one
True, yes, not a bad idea.  Alternatively, if we're going to have a

collection of such things, they could be housed in a subdirectory
somewhere.  Projects will often carry configs for vim, emacs, and
other
editors...  Having them in one place might also make it easier to
spot
discrepancies in each other's formatting configurations.
Bryce

[Marc Jeanmougin]

[...]

Post by Bryce Harrington

Post by Jabier Arraiza

Post by Bryce Harrington
+ _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.

Is a similar objective than astylerc both need external programs to
run maybe we need to select the less intrusibe or the best OS
compatibility one

True, yes, not a bad idea. Alternatively, if we're going to have a
collection of such things, they could be housed in a subdirectory
somewhere. Projects will often carry configs for vim, emacs, and other
editors... Having them in one place might also make it easier to spot
discrepancies in each other's formatting configurations.

clang-format is similar to astyle, but it has the advantage that we can
use it directly without moving the style file: from the man page, iirc
clang-format looks for .clang-format files situated in parent
directories of the formatted file(s).

(Side note: I'd actually be in favor of automatically running
clang-format on MR if it's technically possible (a possibility would be
to run it as a "test" and prevent merges of branches that make tests fail))

[Alex Valavanis]

The gtest download script could be removed by adding the googletest
source as a git submodule within the Inkscape repo... this is how it's
done in 2geom.

**BUT** I don't think that Launchpad supports submodules, so this
could cause issues with PPA builds.

Does anyone know a way round this?


AV

Post by Marc Jeanmougin
[...]

Post by Bryce Harrington

Post by Jabier Arraiza

Post by Bryce Harrington
+ _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.

Is a similar objective than astylerc both need external programs to
run maybe we need to select the less intrusibe or the best OS
compatibility one

True, yes, not a bad idea. Alternatively, if we're going to have a
collection of such things, they could be housed in a subdirectory
somewhere. Projects will often carry configs for vim, emacs, and other
editors... Having them in one place might also make it easier to spot
discrepancies in each other's formatting configurations.

clang-format is similar to astyle, but it has the advantage that we can
use it directly without moving the style file: from the man page, iirc
clang-format looks for .clang-format files situated in parent
directories of the formatted file(s).
(Side note: I'd actually be in favor of automatically running
clang-format on MR if it's technically possible (a possibility would be
to run it as a "test" and prevent merges of branches that make tests fail))
--
Marc
------------------------------------------------------------------------------
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

[Sylvain Chiron]

If you can setup submodules in the Inkscape repository, then I could
probably also use submodules for libavoid/libcola/libvspc from the
Adaptagrams project (I updated these libraries in the Inkscape repo
during the hackfest); then these directories could be removed from src/.

https://github.com/mjwybrow/adaptagrams/

Sylvain

Post by Alex Valavanis
The gtest download script could be removed by adding the googletest
source as a git submodule within the Inkscape repo... this is how it's
done in 2geom.
**BUT** I don't think that Launchpad supports submodules, so this
could cause issues with PPA builds.
Does anyone know a way round this?
AV

Post by Marc Jeanmougin
[...]

Post by Bryce Harrington

Post by Jabier Arraiza

Post by Bryce Harrington
+ _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.

Is a similar objective than astylerc both need external programs to
run maybe we need to select the less intrusibe or the best OS
compatibility one

True, yes, not a bad idea. Alternatively, if we're going to have a
collection of such things, they could be housed in a subdirectory
somewhere. Projects will often carry configs for vim, emacs, and other
editors... Having them in one place might also make it easier to spot
discrepancies in each other's formatting configurations.

clang-format is similar to astyle, but it has the advantage that we can
use it directly without moving the style file: from the man page, iirc
clang-format looks for .clang-format files situated in parent
directories of the formatted file(s).
(Side note: I'd actually be in favor of automatically running
clang-format on MR if it's technically possible (a possibility would be
to run it as a "test" and prevent merges of branches that make tests fail))
--
Marc
------------------------------------------------------------------------------
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

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

[Alex Valavanis]

This would also be highly desirable, but we should ensure that Inkscape can
still build on systems that don't support submodules.

I.e., if the adaptagrams folder can't be found, print a warning and exclude
the connector tool code from the build. I did a similar thing with Potrace.

Post by Sylvain Chiron
If you can setup submodules in the Inkscape repository, then I could
probably also use submodules for libavoid/libcola/libvspc from the
Adaptagrams project (I updated these libraries in the Inkscape repo
during the hackfest); then these directories could be removed from src/.
https://github.com/mjwybrow/adaptagrams/
Sylvain

Post by Alex Valavanis
The gtest download script could be removed by adding the googletest
source as a git submodule within the Inkscape repo... this is how it's
done in 2geom.
**BUT** I don't think that Launchpad supports submodules, so this
could cause issues with PPA builds.
Does anyone know a way round this?
AV

Post by Marc Jeanmougin
[...]

Post by Bryce Harrington

Post by Jabier Arraiza

Post by Bryce Harrington
+ _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.

Is a similar objective than astylerc both need external programs to
run maybe we need to select the less intrusibe or the best OS
compatibility one

True, yes, not a bad idea. Alternatively, if we're going to have a
collection of such things, they could be housed in a subdirectory
somewhere. Projects will often carry configs for vim, emacs, and other
editors... Having them in one place might also make it easier to spot
discrepancies in each other's formatting configurations.

clang-format is similar to astyle, but it has the advantage that we can
use it directly without moving the style file: from the man page, iirc
clang-format looks for .clang-format files situated in parent
directories of the formatted file(s).
(Side note: I'd actually be in favor of automatically running
clang-format on MR if it's technically possible (a possibility would be
to run it as a "test" and prevent merges of branches that make tests

fail))

Post by Alex Valavanis

Post by Marc Jeanmougin
--
Marc
------------------------------------------------------------

------------------

Post by Alex Valavanis

Post by Marc Jeanmougin
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

------------------------------------------------------------

------------------

Post by Alex Valavanis
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

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

[Sylvain Chiron]

Post by Alex Valavanis
This would also be highly desirable, but we should ensure that Inkscape
can still build on systems that don't support submodules.

Why? What can be a system that doesn’t support submodules? Aren’t there
managed by Git?
--
Sylvain

[Tobias Ellinghaus]

Post by Alex Valavanis
This would also be highly desirable, but we should ensure that Inkscape
can still build on systems that don't support submodules.

Why? What can be a system that doesn’t support submodules? Aren’t there
managed by Git?

"git archive" doesn't include submodules, so anything that uses a tarball
generated from that will miss parts of the sources.

--
Sylvain

Tobias

[Alex Valavanis]

I attempted to sync the code for my other project
(launchpad.net/qwwad) from github to Launchpad so I could build a PPA
from a source recipe... it seems that git submodules were ignored in
the import!

AV

Post by Tobias Ellinghaus

Post by Sylvain Chiron

Post by Alex Valavanis
This would also be highly desirable, but we should ensure that Inkscape
can still build on systems that don't support submodules.

Why? What can be a system that doesn’t support submodules? Aren’t there
managed by Git?

"git archive" doesn't include submodules, so anything that uses a tarball
generated from that will miss parts of the sources.

Post by Sylvain Chiron
--
Sylvain

Tobias
------------------------------------------------------------------------------
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]

I'm concerned about reports like these of compatibility issues when
using git submodules.

I haven't used git submodules myself but I have used similar
functionality in other VCS's in the past and had similar experiences
with them causing problems integrating with other tools, and needing
more manual attention and management than expected.

I suspect it will be easier for especially new devs if we stick with
external dependencies for what can be external, and copied-in code for
whatever can't, and focus on minimizing the latter and maximizing the
former as much as possible.

Bryce

Post by Alex Valavanis
I attempted to sync the code for my other project
(launchpad.net/qwwad) from github to Launchpad so I could build a PPA
from a source recipe... it seems that git submodules were ignored in
the import!
AV

Post by Tobias Ellinghaus

Post by Sylvain Chiron

Post by Alex Valavanis
This would also be highly desirable, but we should ensure that Inkscape
can still build on systems that don't support submodules.

Why? What can be a system that doesn’t support submodules? Aren’t there
managed by Git?

"git archive" doesn't include submodules, so anything that uses a tarball
generated from that will miss parts of the sources.

Post by Sylvain Chiron
--
Sylvain

Tobias
------------------------------------------------------------------------------
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

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

[Alex Valavanis]

As I understand it, the only reason why we maintain a fork of Adaptagrams
is that there isn't an upstream release yet.

Is anyone in touch with the upstream Adaptagrams dev (M Wybrow)? If we
could persuade him to make a release tarball, perhaps we can get it adopted
by some distros... and then finally drop our fork!

AV

Post by Bryce Harrington
I'm concerned about reports like these of compatibility issues when
using git submodules.
I haven't used git submodules myself but I have used similar
functionality in other VCS's in the past and had similar experiences
with them causing problems integrating with other tools, and needing
more manual attention and management than expected.
I suspect it will be easier for especially new devs if we stick with
external dependencies for what can be external, and copied-in code for
whatever can't, and focus on minimizing the latter and maximizing the
former as much as possible.
Bryce

Post by Alex Valavanis
I attempted to sync the code for my other project
(launchpad.net/qwwad) from github to Launchpad so I could build a PPA
from a source recipe... it seems that git submodules were ignored in
the import!
AV

Post by Tobias Ellinghaus

Post by Alex Valavanis
This would also be highly desirable, but we should ensure that

Inkscape

Post by Alex Valavanis

Post by Tobias Ellinghaus

Post by Alex Valavanis
can still build on systems that don't support submodules.

Why? What can be a system that doesn’t support submodules? Aren’t

there

Post by Alex Valavanis

Post by Tobias Ellinghaus

managed by Git?

"git archive" doesn't include submodules, so anything that uses a

tarball

Post by Alex Valavanis

Post by Tobias Ellinghaus
generated from that will miss parts of the sources.

--
Sylvain

Tobias
------------------------------------------------------------

------------------

Post by Alex Valavanis

Post by Tobias Ellinghaus
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

------------------------------------------------------------

------------------

Post by Alex Valavanis
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

[Martin Owens]

Post by Alex Valavanis
As I understand it, the only reason why we maintain a fork of
Adaptagrams is that there isn't an upstream release yet.
Is anyone in touch with the upstream Adaptagrams dev (M Wybrow)?  If
we could persuade him to make a release tarball, perhaps we can get
it adopted by some distros... and then finally drop our fork!

It's not necessary to have a cooperative upstream (though it is much
nicer) you can build the tarballs from a fork, publish them on github
and kick the distros into packaging mode.

I would have preferred we do it this way than bringing in the
adaptergrams code into our codebase. But I understand there are
complications with different platforms.

Best Regards, Martin Owens

[Bryce Harrington]

Post by Martin Owens

Post by Alex Valavanis
As I understand it, the only reason why we maintain a fork of
Adaptagrams is that there isn't an upstream release yet.
Is anyone in touch with the upstream Adaptagrams dev (M Wybrow)?  If
we could persuade him to make a release tarball, perhaps we can get
it adopted by some distros... and then finally drop our fork!

It's not necessary to have a cooperative upstream (though it is much
nicer) you can build the tarballs from a fork, publish them on github
and kick the distros into packaging mode.

That might be a good practice to adopt in general for situations like
this.

Bryce

Post by Martin Owens
I would have preferred we do it this way than bringing in the
adaptergrams code into our codebase. But I understand there are
complications with different platforms.
Best Regards, Martin Owens

[Alex Valavanis]

I've emailed the Adaptagrams dev to see if he's keen to press a
release. Otherwise, we can package it as Martin suggests :)

AV

Post by Bryce Harrington

Post by Martin Owens

Post by Alex Valavanis
As I understand it, the only reason why we maintain a fork of
Adaptagrams is that there isn't an upstream release yet.
Is anyone in touch with the upstream Adaptagrams dev (M Wybrow)? If
we could persuade him to make a release tarball, perhaps we can get
it adopted by some distros... and then finally drop our fork!

It's not necessary to have a cooperative upstream (though it is much
nicer) you can build the tarballs from a fork, publish them on github
and kick the distros into packaging mode.

That might be a good practice to adopt in general for situations like
this.
Bryce

Post by Martin Owens
I would have preferred we do it this way than bringing in the
adaptergrams code into our codebase. But I understand there are
complications with different platforms.
Best Regards, Martin Owens

[Bryce Harrington]

Great, sounds like a good approach, thanks for emailing him. :-)

Post by Alex Valavanis
I've emailed the Adaptagrams dev to see if he's keen to press a
release. Otherwise, we can package it as Martin suggests :)
AV

Post by Bryce Harrington

Post by Martin Owens

Post by Alex Valavanis
As I understand it, the only reason why we maintain a fork of
Adaptagrams is that there isn't an upstream release yet.
Is anyone in touch with the upstream Adaptagrams dev (M Wybrow)? If
we could persuade him to make a release tarball, perhaps we can get
it adopted by some distros... and then finally drop our fork!

It's not necessary to have a cooperative upstream (though it is much
nicer) you can build the tarballs from a fork, publish them on github
and kick the distros into packaging mode.

That might be a good practice to adopt in general for situations like
this.
Bryce

Post by Martin Owens
I would have preferred we do it this way than bringing in the
adaptergrams code into our codebase. But I understand there are
complications with different platforms.
Best Regards, Martin Owens

[Mattia Rizzolo]

Post by Alex Valavanis
I attempted to sync the code for my other project
(launchpad.net/qwwad) from github to Launchpad so I could build a PPA
from a source recipe... it seems that git submodules were ignored in
the import!

Yes, that's a launchpad bug. About to be fixed:
https://bugs.launchpad.net/launchpad-buildd/+bug/1694413

[Alex Valavanis]

This is great news... thanks for the bug link.

@Bryce - I still think git submodules are a good idea; there's nothing
intrinsically difficult from a developer's perspective after initial
config, and this fix in LP should allow us to run PPA builds.
Anything we can do to minimise unnecessary forks of upstream library
code sounds like a good thing to me! For safety, we can just add
tests to the CMake scripts to allow a feature-incomplete build if the
submodules have failed to pull for whatever reason.

AV

Post by Mattia Rizzolo

Post by Alex Valavanis
I attempted to sync the code for my other project
(launchpad.net/qwwad) from github to Launchpad so I could build a PPA
from a source recipe... it seems that git submodules were ignored in
the import!

https://bugs.launchpad.net/launchpad-buildd/+bug/1694413
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-

[Martin Owens]

Post by Alex Valavanis
The gtest download script could be removed by adding the googletest
source as a git submodule within the Inkscape repo... this is how it's
done in 2geom.
**BUT** I don't think that Launchpad supports submodules, so this
could cause issues with PPA builds.
Does anyone know a way round this?

Is gtest required for building or is it just a testing patch?

Martin,

[Alex Valavanis]

I'm not sure, but gtest *should* only be required at the point of invoking
"make check". I.e., it should be possible to build and install Inkscape on
a user system without having a test suite available.

Once that's in place, we can simply disable the auto_test macro in the PPA,
so it'll happily build without testing. This shouldn't be a problem as we
now run Ubuntu tests independently in our CI config.

AV

Post by Martin Owens

Post by Alex Valavanis
The gtest download script could be removed by adding the googletest
source as a git submodule within the Inkscape repo... this is how it's
done in 2geom.
**BUT** I don't think that Launchpad supports submodules, so this
could cause issues with PPA builds.
Does anyone know a way round this?

Is gtest required for building or is it just a testing patch?
Martin,

[Maren Hachmann]

Post by Alex Valavanis
I'm not sure, but gtest *should* only be required at the point of
invoking "make check". I.e., it should be possible to build and install
Inkscape on a user system without having a test suite available.

- I don't have google test installed, and trunk builds just fine for me
(last time I tried, at least - on July 10th). After running cmake, it
tells me that it's going to compile with google test turned off.

Maren

Post by Alex Valavanis
Once that's in place, we can simply disable the auto_test macro in the
PPA, so it'll happily build without testing. This shouldn't be a
problem as we now run Ubuntu tests independently in our CI config.
AV

Post by Alex Valavanis
The gtest download script could be removed by adding the googletest
source as a git submodule within the Inkscape repo... this is how it's
done in 2geom.
**BUT** I don't think that Launchpad supports submodules, so this
could cause issues with PPA builds.
Does anyone know a way round this?

Is gtest required for building or is it just a testing patch?
Martin,
------------------------------------------------------------------------------
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

[Sylvain Chiron]

Hi,

Post by Eduard Braun

Post by Bryce Harrington
------------------------------------------------------------------------
+ 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?

I added support for gtest 1.8 in 6b8520e which should now be
auto-detected by cmake if installed in the system (tested on Windows,
maybe somebody on Linux with gtest 1.8 installed could cross-check).
If we're fine to require gtest >= 1.8 (it's the first to include gmock)
we can drop the script already (plus some legacy cmake code). Otherwise
we'd require some additional code.

Running CMake normally to setup Inkscape compilation, I get the
following message:

CMake Warning at CMakeLists.txt:102 (find_package):
By not providing "Findgtest.cmake" in CMAKE_MODULE_PATH
this project has asked CMake to find a package configuration file
provided by "gtest", but CMake did not find one.

Could not find a package configuration file provided by "gtest" with
any of the following names:

gtestConfig.cmake
gtest-config.cmake

Add the installation prefix of "gtest" to CMAKE_PREFIX_PATH or set
"gtest_DIR" to a directory containing one of the above files. If
"gtest" provides a separate development package or SDK, be sure it
has been installed.

I’m under Arch Linux and I installed the package ‘gtest’ (so it’s
installed in /usr) but the message still appears.

Post by Eduard Braun
------------------------------------------------------------------------
+ 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?

From a translator’s point of view: there are no instructions on
inkscape.org and the wiki for translating these files. One day I
discovered them and updated/revised README.fr.txt.

Having a README file in our repository is a standard, but managing
translations involves a complex process, and in any case development is
done exclusively in English so translations are quite irrelevant there.
The website allows to communicate with non-English speakers if needed.

The files doc/HACKING.*.txt could be removed too (and doc/HACKING.txt
could be Markdown’ed).

Post by Eduard Braun
------------------------------------------------------------------------
+ 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.

I didn’t test the file but I think its usage should be encouraged. I’m
very disturbed, looking at the code, by the irregularity of the files —
I saw tabs, misplaced braces, etc. And as a newbie developer I don’t
feel comfortable committing files just for astyling them. Maybe you
could rename the file to ‘.astylerc’ for the cleaning.

I like when things are concise, clear and standardized so that I can
master them very quickly — the smallest mess always troubles me. Thus I
thank you very much for any cleaning.

Regards,
--
Sylvain

[Bryce Harrington]

Post by Sylvain Chiron
Hi,

Post by Eduard Braun

Post by Bryce Harrington
------------------------------------------------------------------------
+ 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?

I added support for gtest 1.8 in 6b8520e which should now be
auto-detected by cmake if installed in the system (tested on Windows,
maybe somebody on Linux with gtest 1.8 installed could cross-check).
If we're fine to require gtest >= 1.8 (it's the first to include gmock)
we can drop the script already (plus some legacy cmake code). Otherwise
we'd require some additional code.

Running CMake normally to setup Inkscape compilation, I get the
By not providing "Findgtest.cmake" in CMAKE_MODULE_PATH
this project has asked CMake to find a package configuration file
provided by "gtest", but CMake did not find one.
Could not find a package configuration file provided by "gtest" with
gtestConfig.cmake
gtest-config.cmake
Add the installation prefix of "gtest" to CMAKE_PREFIX_PATH or set
"gtest_DIR" to a directory containing one of the above files. If
"gtest" provides a separate development package or SDK, be sure it
has been installed.
I’m under Arch Linux and I installed the package ‘gtest’ (so it’s
installed in /usr) but the message still appears.

Under Ubuntu there is a libgtest-dev but having it installed doesn't
alter the warning. I see it is installing various stuff to
/usr/src/gtest, /usr/include/gtest, and /usr/include/gtest/internal.

Post by Sylvain Chiron

Post by Eduard Braun
------------------------------------------------------------------------
+ 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?
From a translator’s point of view: there are no instructions on

inkscape.org and the wiki for translating these files. One day I
discovered them and updated/revised README.fr.txt.

Early on in the translation efforts we did have some informal process
for them, but I don't think it ever got systematized and organized the
way other translatable things did.

Post by Sylvain Chiron
Having a README file in our repository is a standard, but managing
translations involves a complex process, and in any case development is
done exclusively in English so translations are quite irrelevant there.
The website allows to communicate with non-English speakers if needed.

Ok, yeah that is what I suspected. And good point about the added
complexities involved in being able to maintain translations in-repo
like this.

Post by Sylvain Chiron
The files doc/HACKING.*.txt could be removed too (and doc/HACKING.txt
could be Markdown’ed).

Yes. Also, HACKING.txt is painfully out of date; half of it is now
obsolete with autotools gone.

There are some development policies and policies here that are worth
preserving. HACKING.txt has been our official place to keep them but no
particular reason it has to be so, if there's a more visible place to
keep this type of info (like the gitlab wiki?)

Bryce

Post by Sylvain Chiron

Post by Eduard Braun
------------------------------------------------------------------------
+ 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.

I didn’t test the file but I think its usage should be encouraged. I’m
very disturbed, looking at the code, by the irregularity of the files —
I saw tabs, misplaced braces, etc. And as a newbie developer I don’t
feel comfortable committing files just for astyling them. Maybe you
could rename the file to ‘.astylerc’ for the cleaning.
I like when things are concise, clear and standardized so that I can
master them very quickly — the smallest mess always troubles me. Thus I
thank you very much for any cleaning.
Regards,
--
Sylvain
------------------------------------------------------------------------------
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

[Eduard Braun]

Post by Bryce Harrington

Post by Sylvain Chiron
Hi,

Post by Eduard Braun

Post by Bryce Harrington
------------------------------------------------------------------------
+ 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?

I added support for gtest 1.8 in 6b8520e which should now be
auto-detected by cmake if installed in the system (tested on Windows,
maybe somebody on Linux with gtest 1.8 installed could cross-check).
If we're fine to require gtest >= 1.8 (it's the first to include gmock)
we can drop the script already (plus some legacy cmake code). Otherwise
we'd require some additional code.

Running CMake normally to setup Inkscape compilation, I get the
By not providing "Findgtest.cmake" in CMAKE_MODULE_PATH
this project has asked CMake to find a package configuration file
provided by "gtest", but CMake did not find one.
Could not find a package configuration file provided by "gtest" with
gtestConfig.cmake
gtest-config.cmake
Add the installation prefix of "gtest" to CMAKE_PREFIX_PATH or set
"gtest_DIR" to a directory containing one of the above files. If
"gtest" provides a separate development package or SDK, be sure it
has been installed.
I’m under Arch Linux and I installed the package ‘gtest’ (so it’s
installed in /usr) but the message still appears.

Under Ubuntu there is a libgtest-dev but having it installed doesn't
alter the warning. I see it is installing various stuff to
/usr/src/gtest, /usr/include/gtest, and /usr/include/gtest/internal.

I pushed [1] earlier today which might have fixed the issue you're
seeing. Did your checkouts have that commit already?

@Sylvain:
Arch Linux' gtest does not seem to include gmock, so you might need to
install the latter package separately

@bryce:
As for libgtest-dev you need at least version 1.8.0 (which should
include gmock and additionally install into /usr/include/gmock and
/usr/include/gmock/internal).
If I understand correctly libgtest-dev [2] will eventually be renamed to
googletest [3] (libgtest-dev 1.8.0 depends on the latter already), at
least that's what debian says (see NOTE in [4]).

Regards,
Eduard

[1]
https://gitlab.com/inkscape/inkscape/commit/ae330137b0b70f2d1a3f704c1bd0758ca4929830
[2] https://packages.ubuntu.com/search?keywords=libgtest-dev+&searchon=names
[3] https://packages.ubuntu.com/search?keywords=googletest&searchon=names
[4] https://packages.debian.org/stretch/libgtest-dev

[Sylvain Chiron]

Post by Eduard Braun
I pushed [1] earlier today which might have fixed the issue you're
seeing. Did your checkouts have that commit already?

No. It works, thanks — :). Indeed I have this file:
/usr/share/cmake-3.8/Modules/FindGTest.cmake

Post by Eduard Braun
Arch Linux' gtest does not seem to include gmock, so you might need to
install the latter package separately

Yes, I did.
--
Sylvain

[Eduard Braun]

Post by Bryce Harrington
------------------------------------------------------------------------
+ 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.

I removed those files from the build directory in
https://gitlab.com/inkscape/inkscape/commit/4ac8f396a182002b1523684c0455c1277114ab7b

They were actually autotools remnants and the files now used by cmake
are in /man.

We need to make sure not to update those files directly though. man
files and their translations are updated at
http://bazaar.launchpad.net/~inkscape.dev/inkscape-docs/trunk/files/head:/man/

Unfortunately the repository does not seem to have been updated for a
cmake build yet, so somebody needs to do the necessary adjustments
(maybe by starting to move inkscape-docs to GitLab?)
jazzynico was doing most of the updates so maybe he already has some
scripts handy (CC'ing).

Regards,
Eduard

[Bryce Harrington]

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?

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.

Post by Bryce Harrington
------------------------------------------------------------------------
+ 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.

Post by Bryce Harrington
------------------------------------------------------------------------
+ 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.

Post by Bryce Harrington
------------------------------------------------------------------------
+ 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.

Post by Bryce Harrington
------------------------------------------------------------------------
+ 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.

Post by Bryce Harrington
------------------------------------------------------------------------
+ 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.

Post by Bryce Harrington
------------------------------------------------------------------------
+ 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.

Post by Bryce Harrington
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...)

Post by Bryce Harrington
------------------------------------------------------------------------
+ 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