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.
Le 15/07/2017 à 01:41, Bryce Harrington a écrit :
------------------------------------------------------------------------
+ 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).
------------------------------------------------------------------------
+ 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