On Sun, Jun 11, 2017 at 12:02:44PM +0200, Maximilian Gaukler wrote:

Hi everyone,

I would like to propose a change to this page: https://inkscape.org/en/develop/getting-started/#install-build-dependencies

Currently, the section "Install build dependencies" doesn't constructively explain how to build the latest trunk without enabling some PPA.

But, lucky enough, there is already a nice listing of apt-get commands in this file: https://gitlab.com/inkscape/inkscape/blob/master/.gitlab-ci.yml As it is used in the CI (automatic build), it is automatically checked that the commands there actually work for the current version.

Therefore, I'd suggest the following change: (pseudo-patch-file, - = remove, + = insert)

• Note: If you are using the PPA for the latest builds on Debian, you
• can use this alternative command to get a more accurate set of build
• dependencies:
• sudo apt-get build-dep inkscape-trunk Note that this will install the build dependencies of the Inkscape package available in your repositories. If the package is old, you might need to install some additional dependencies
• ;

• .
• A more accurate set of build dependencies
• can be found in this file in the lines containing 'apt-get':
• https://gitlab.com/inkscape/inkscape/blob/master/.gitlab-ci.yml

• the output of the configure script should give you hints on what
• else is required.

• In case of errors, the output of 'cmake' should give you hints on what
• else is required.

Looks good to me, clever reuse of the CI scripts. They look comprehensible enough in current form.

Note the CI was just set up, while the PPAs haven't been transitioned, so yes the former does give more accurate results right now, however we'll get them both working so either approach *should* work. The PPA / build-dep approach might be a bit more future proof since it will by definition work with a range of support ubuntu versions (and debian), but yes having to enable a PPA in order to build from source does seem awkward.

Also, the doc/HACKING.* files are really outdated (many technical details are wrong), I would suggest simply replacing them with a link to the develop/getting-started website. If it helps, I can hand in a merge request for that, or a launchpad bug report, or whatever is the right thing during the migration to GIT.

Yeah you're right they've not been kept up to date. Technically HACKING should not be covering build directions anyway - that should be covered in other files. But the remainder are essentially our "development policy" and should remain; however what they're describing is development policy as it existed years ago. Obviously we still need to have our policies written down (and I don't think wiki is the right place - ref. my Jan 29th proposal on wiki restructuring). With the gitlab transition there's been a lot of questions about policy changes, so this'd be a good point to re-discuss and re-document all of that anyway.

Bryce