The content of this repository was reunited with the history of it's ancestors. It's archived now to keep all former release artifacts. The new repository is available at https://github.com/aliascash/alias-wallet
It's important for the build process itself, that it's possible to make some kind of a "one-shot" build, which generates/builds everything. That's already possible. Additional to this the build scripts can build either only the dependencies or only the wallet binaries. That's important for fast continuous builds, so they can use the existing pre-build dependencies. As already said, that's already possible right now.
If using Qt Creator, it "scan's to death" the whole project directory respectively Git clone again and again because of the pre-build dependencies, which are also below a certain build folder on the root directory of the Git clone. So it looks like the behaviour of Qt Creator is something the other way around than pure CMake works. In simple words: On CMake you go into the build directory and start the build inside this directory and point CMake to the location where the sources are. So they are usually one folder level up, as the build directory is located on the root level of the Git clone. So you can have multiple build directories i. e. for different target architectures and that's how the current build scripts work. In contrast Qt Creator is operating at Git clone root level and so it "finds and scans" the directories with the pre-build dependencies.
To solve the issue but not wipe out current functionality, it should be possible to define the location of the pre-build dependencies with a given path, so they are located outside the local Git clone. If not already there, they should be built on the given path.
Solution with this PR: With a new cmd line option it is possible to pass the path to the pre-build library location to the build script. This path will be stored on scripts/.buildproperties. After that the script will check, if the required binaries, headers etc. are on this given location and if not, build the corresponding dependency there. So on subsequent builds one could omit the new option because the script finds and uses the path to the pre-build dependencies as it is stored on scripts/.buildconfig. With this approach it's possible to have the pre-build dependencies once on the machine somewhere outside the Git clone (or even in different versions on different locations) and can use them from different clones. Additionally the issue on Qt Creator is solved as the Git clone respectively the project on Qt Creator contains only the project sources and no longer any other stuff from the required dependencies.
It's important for the build process itself, that it's possible to make some kind of a "one-shot" build, which generates/builds everything. That's already possible. Additional to this the build scripts can build either only the dependencies or only the wallet binaries. That's important for fast continuous builds, so they can use the existing pre-build dependencies. As already said, that's already possible right now.
If using Qt Creator, it "scan's to death" the whole project directory respectively Git clone again and again because of the pre-build dependencies, which are also below a certain build folder on the root directory of the Git clone. So it looks like the behaviour of Qt Creator is something the other way around than pure CMake works. In simple words: On CMake you go into the build directory and start the build inside this directory and point CMake to the location where the sources are. So they are usually one folder level up, as the build directory is located on the root level of the Git clone. So you can have multiple build directories i. e. for different target architectures and that's how the current build scripts work. In contrast Qt Creator is operating at Git clone root level and so it "finds and scans" the directories with the pre-build dependencies. To solve the issue but not wipe out current functionality, it should be possible to define the location of the pre-build dependencies with a given path, so they are located outside the local Git clone. If not already there, they should be built on the given path.
Solution with this PR: With a new cmd line option it is possible to pass the path to the pre-build library location to the build script. This path will be stored on
scripts/.buildproperties. After that the script will check, if the required binaries, headers etc. are on this given location and if not, build the corresponding dependency there. So on subsequent builds one could omit the new option because the script finds and uses the path to the pre-build dependencies as it is stored onscripts/.buildconfig. With this approach it's possible to have the pre-build dependencies once on the machine somewhere outside the Git clone (or even in different versions on different locations) and can use them from different clones. Additionally the issue on Qt Creator is solved as the Git clone respectively the project on Qt Creator contains only the project sources and no longer any other stuff from the required dependencies.