Hi!

I've created a copy of Krita's Git repo on Bitbucket. You can preview the 3rdparty/README.md file at https://bitbucket.org/ablondin/krita-private/src/8f0fc07084f16e89f47d4f0716e79d242adfaea8/3rdparty?at=refactoring-3rdparty-readme. If you want me to remove outdated parts in my patch, I can do it without problem, but I haven't identified any for now. In particular, I don't have access to any Windows machine, so that I can't test it (just MacOS for now, but I also have Debian at work, which I didn't test so far).

Alexandre

I also thought about splitting the build instructions into three files, but I'm not sure if it's a good idea. Anyway, since I'm new to Krita's development, I am aware I can suggest wrong ideas, so feel free to ask for improvement :)

I think we can just say "MSVC is not supported at the moment" and leave it at that. I think that having one file is more convenient than 3 because it's a single link we can hand out to interested people.

Oh, and the common issues probably also need to be moved to the correct OS instructions.

Ok, thanks! I'll change the patch accordingly.

In D3882#73478, @dkazakov wrote:

Hi, @alvinhochun!

I'm a bit of afraid that having these lines duplicated in three places will make the build instructions unmaintainable. Especially if we take into account that Boud is the only person who can build Krita on all the three operating systems. It means that others will modify only their parts and they will become out of sync really quickly.

Actually I don't think we should split the whole file. I think it's fine to keep the sections (i.e. intro / prerequisites / environment setup / building / packaging) and then split the contents in each section.

The "Build Krita" section has mostly distinct commands so splitting it should be fine.

My main concern is with the chunk of steps on building the 3rdparty dependencies. A lot of those commands are for building individual targets and most are shared by all three OSes, but some platform-specific commands are inserted in between which breaks the flow. But it might be worth mentioning that one also shouldn't just directly copy all the commands and paste it into a terminal, or a batch script, because the commands *can* fail for various reasons (Internet is one.) Due to how the CMakeLists is set up, the commands have to be executed sequentially or else it may not work... So, however they are arranged, one would still be running them one by one. You can argue there aren't really any benefit.

Maybe we can put in full scripts with error checking, but the documentation would still be needed so they'd end up being extra things having to be maintained.

An alternative is to "fix" the CMakeLists by setting up the dependencies correctly (or just somehow make them build in order,) perhaps also include a dummy target to just build all of them (maybe with options) so it can be done in just a few commands. But this also makes the 3rdparty more complicated to maintain, and Boud is the one doing so...

Also consider that the 3rdparty dependencies are not updated often. It might be better to have a checklist so none of the stuff is forgotten.

Hi, @alvinhochun!

Scripting for 3rdparty is a nice thing, but I feel that providing developers with a prebuilt tarball will be much more efficient with both time-to-build and maintainance point of view. I really liked how Boud's file was layout. Basically, it looked like a script with 'ifdef's for each OS on every step. It allows us to see the difference between different OS build steps in a single glance.

In T4986#73457, @dkazakov wrote:

Hi, @alvinhochun!

Scripting for 3rdparty is a nice thing, but I feel that providing developers with a prebuilt tarball will be much more efficient with both time-to-build and maintainance point of view. [...]

It'd be a bit tricky because iirc some of the generated files seem to have absolute file paths hard-coded in. There are ways to work around that, but they're not convenient...

C:\dev is a sane choice for getting started quickly, fine for systems that does only one thing (e.g. VM / build server,) but some might prefer having more organized folder structures.

That reminds me, in the doc there needs to be a note on the maximum path length on Windows.

I did a bit of searching and found these pages that contains some sort of build instructions:

On wiki:

• KDE UserBase Wiki - Krita/Manual/Installation - no actual instructions, but has a link to David Revoy's guide, and a link to Calligra/Building which should probably be changed to a more appropriate page.
• KDE Community Wiki - Krita - has a few links to other pages which seems fine, some notes:
  • David Revoy's guide might not be suitable for building 2.9 anymore
  • Krita/linuxbuild - Linux (probably should work)
  • Krita/Winbuild - the link says "Build Krita 2.9.x on Windows" but the page itself doesn't state that, and it's pretty much old instructions
  • Krita/30Winbuild - still references VS2015, and it just references 3rdparty/README.md anyway.
  • Krita/Emergebuild - don't know if this still works
  • Krita/osxbuild - looks ok but also just references 3rdparty/README.md

The few points to consider:

• Should instructions for building older versions be kept?
• Should there be more complete instructions on the wiki, or just simply references 3rdparty/README.md?
• Should there be another README.md or COMPILING.md outlining the instructions for alternative building instructions (i.e. not using the 3rdparty directory)?
• How about https://docs.krita.org/?

Also, instructions on external sites (I think they are worth listing for completeness):

• Building Krita 3.0 on Linux for cats - Linux (I guess this should still work for latest)
• Building Krita 3.0 for lazy cats - Linux (seems fine)

I think our build instructions are fine now, do we need to keep this task here?