README mini build & install guide

[rturrado]

The online version of ReadTheDocs is not updated with the latest changes. As part of this PR, we'll make sure it will be.
I've also taken the opportunity to add a mini build & install guide to the README file, similar to what we have for libqasm.
And, in doing so, I've updated the Dependencies section of the Build instructions in ReadTheDocs.

[pablolh]

why does the C++ standard has to be specified in this command?

[pablolh]

I approve of the review btw, but it's already merged anyway

[rturrado]

why does the C++ standard has to be specified in this command?

Good question Pablo. I think it is not enough specifying it in the CMake file. I think to remember having some compiling issues for not specifying it. However, I'm not 100% sure so I'm going to double check this, maybe remove it in a future. Thanks!

[rturrado]

I approve of the review btw, but it's already merged anyway

Yes, sorry about that. I saw that Hans approved the PR this morning, so I quickly merged it, thinking it wasn't dangerous to have it in.

Anyway, I still have to work out with your help:

1. How can I update the ReadTheDocs? Can I access the server that builds the docs and manually fire a build?
2. Would it be possible to change the automatic building of the docs to be done after every PR at least, instead of after every release?

[rturrado]

why does the C++ standard has to be specified in this command?

Good question Pablo. I think it is not enough specifying it in the CMake file. I think to remember having some compiling issues for not specifying it. However, I'm not 100% sure so I'm going to double check this, maybe remove it in a future. Thanks!

I have just checked. Without specifying the version, Conan tried to use C++11.

[pablolh]

I'm absolutely fine with the merging of this PR :) ! Was just curious

Conan tried to use C++11

Ah, weird, maybe there's a setting in some Conan file that you can use instread of having to specify it on the command line?

[rturrado]

I think so. Profiles may help here. You should be able to pack all the options together in a profile, let's say x64-linux-debug, and then run it the next way: conan build . -pr x64-linux-debug.

Actually, for what I've just read, you could edit the default profile (the one that is created after doing conan profile detect), to set the compiler (for example). So you would do that once for each of your development machines.

This is one of the things I miss the most from CMake. If you have a look at this project of mine, you will see that I was configuring and building it like this:

C:\projects\the_modern_cpp_challenge> cmake --preset windows-msvc-debug-tests
C:\projects\the_modern_cpp_challenge> cmake --build --preset windows-msvc-debug-tests

Those presets were defined in a CMakePresets.json file. You could define some base presets, then specialize them, defining different options for each one...

Anyway, thanks for the comment because those Conan command lines we have at the moment are very unattractive. I know one can always create bash aliases, e.g. build_openql_debug or whatever, but it would be great to just download something and build it with a shorter command.

[rturrado]

A little update on this conversation.

I have started using a CLion's Conan plugin, and as a result of the conversation for this issue that I opened, I've found out that:

1. If you set CMAKE_CXX_STANDARD in your project, you don't need to pass the compiler version as a command line parameter. I've noticed we were not doing that in OpenQL.
2. There is a way of not working with command line options at all, but defining them in a profile. For example, we could provide a conan/profiles folder together with the code, including a set of predefined profiles, e.g. tests-release, which would look something like:

include(default)

[settings]
openql/*:build_type=Release
[options]
openql/*:asan_enabled=False
openql/*:build_tests=True
openql/*:disable_unitary=True

And then just compile with conan build . -pr=conan/profiles/tests-release.

Or, these profiles may be copied to the ~./conan2/profiles folder, e.g. for this case, with a name such as openql-tests-release, and then build with conan build . -pr=openql-tests-release.

I'll create a separate PR for addressing these two changes. I think the second one can simplify a lot the user experience.