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 Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

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

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... (@ Sebatian: Do we still need msysenv.sh, see below?) Am 15.07.2017 um 01:41 schrieb 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.

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

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

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 On 15 July 2017 at 01:41, Bryce Harrington <bryce@...961...> wrote: > With the cmake and git conversions complete, and autotools and bzr bits > removed, I am wondering if there's some additional cleanup of stuff > accumulated in our repository's root directory. But much of this I'm > not 100% sure about (and that maybe why others haven't already dealt > with it). > > > ------------------------------------------------------------------------ > + distro > + libgc.supp > + tools-version.sh > > I think these may be obsolete. They've been in the codebase forever, > but I don't know what they are used for anymore. I'm guessing they're > autotools leftovers; can we drop them? > > > ------------------------------------------------------------------------ > + 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 > Inkscape-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel

On Sat, Jul 15, 2017 at 06:39:31PM +0200, Sylvain Chiron wrote: > Hi, > > Le 15/07/2017 à 14:11, Eduard Braun a écrit : >>> ------------------------------------------------------------------------ >>> + 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. 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.

On Sat, 2017-07-15 at 10:32 -0700, Bryce Harrington wrote: On Sat, Jul 15, 2017 at 05:46:14PM +0200, Jabier Arraiza wrote: > Hi Bryce thanks for your deep inform: > > > > --------------------------------------------------------------- > > ---- > > ----- > >  + 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

[...] >>> + _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 Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

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?

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 Le 16/07/2017 à 01:39, Alex Valavanis a écrit : > 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 > > On 16 July 2017 at 00:02, Marc Jeanmougin <marc@...3062...> wrote: >> [...] >>>>> + _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 >> Inkscape-devel(a)lists.sourceforge.net >> 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 > Inkscape-devel(a)lists.sourceforge.net > 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 Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

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

Am Montag, 17. Juli 2017, 14:24:21 CEST schrieb Sylvain Chiron: > Le 16/07/2017 à 13:09, Alex Valavanis a écrit : > > 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 ------------------------------------------------------------------------------ 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 Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

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 On Mon, Jul 17, 2017 at 03:47:58PM +0100, Alex Valavanis wrote: > 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 > > On 17 July 2017 at 15:10, Tobias Ellinghaus <houz@...173...> wrote: > > Am Montag, 17. Juli 2017, 14:24:21 CEST schrieb Sylvain Chiron: > >> Le 16/07/2017 à 13:09, Alex Valavanis a écrit : > >> > 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 > > ------------------------------------------------------------ ------------------ > > 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 > > Inkscape-devel(a)lists.sourceforge.net > > 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 > Inkscape-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel

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!

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

On Mon, Jul 17, 2017 at 07:12:13PM -0400, Martin Owens wrote: > On Mon, 2017-07-17 at 21:40 +0100, Alex Valavanis wrote: > > 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 > 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

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

On Fri, Jul 14, 2017 at 04:41:44PM -0700, Bryce Harrington wrote: > With the cmake and git conversions complete, and autotools and bzr bits > removed, I am wondering if there's some additional cleanup of stuff > accumulated in our repository's root directory. But much of this I'm > not 100% sure about (and that maybe why others haven't already dealt > with it). > > > ------------------------------------------------------------------------ > + inkscape.desktop.in > + inkscape.desktop.template > > Is inkscape.desktop.in generated from inkscape.desktop.template? Do we > need both files? Still unsure here, leaving them for now.

> ------------------------------------------------------------------------ > + mingwenv.bat > + mingwenv.cmake > + msys2checkdeps.py > + msys2installdeps.sh > + msysenv.sh > + inkscape.appdata.xml.in > + Info.plist.in > + appveyor.sh > + appveyor.yml > + .gitlab-ci.yml > + .snapcraft.yaml > + packaging/ > > I know a lot of tools expect config files in the project's root > directory, but can any of these be moved to packaging/? (Or maybe a > utils/ dir?) > > Several of these have description snippets that are essentially the > first few paragraphs of the README. If the README is revised (see > below), it may be worthwhile to resync the text in these from that. Thanks for creating buildtools/ and moving a few items, hopefully we can continue migrating build related utility stuff into there.

> + Info.plist.in > > This appears to be an osx packaging file, last updated in 2014, and a > simple grep seems to indicate that nothing is using it. Can we drop it? > > If not, it looks like the file could be generated. I've removed this one. It was left over from the old Mac packaging implementation. In future it'd either be generated or be a template under 'packaging' or wherever the Mac packaging scripts will live. Cheers, Tim