Am Donnerstag, 14. Januar 2016 um 21:22:43, schrieb Georg Baum <georg.b...@post.rwth-aachen.de> > Am 13.01.2016 um 00:21 schrieb Uwe Stöhr: > > Am 12.01.2016 um 19:43 schrieb Georg Baum: > > > >> Sorry, I still do not understand. Which paths need to be setup? What > >> takes > >> long (a manual step or some program that runs)? > > > > CMake. As soon as I create a new folder and copy there code, I need to > > run CMake from scratch and specify about 40 paths (most of them to Qt). > > If I make a mistake there I get strange builds. > > I agree that this is too much effort, and I would refuse to do this > again and again as well. This is certainly not how the LyX cmake build > is supposed to work. In theory, cmake would only need two paths when > using the bundled 3rdparty sources: Where MSVC is installed, and where > qt is installed. For the latter there is the pseudo standard environment > variable QTDIR, and MSVC provides a nice batch file vcvarsall.bat in the > installation that can be called to set up PATH etc. If you post a list > of these paths then maybe Kornel, Peter or I can help you to find the > correct way of caling cmake.
Yes, and it is totally unneded. The only thing which should be there is the
executable qmake.exe
which has to be in the path. This command allows to find all needed paths.
Since each qt installation has its own qmake, the path has to be set properly.
Example: I have installed qmake in
/usr/BUILD/BuildQt5.4main/5.4/gcc_64/bin/qmake
/usr/BUILD/BuildQt5.5.1main/5.5/gcc_64/bin/qmake
/usr/BUILD/BuildQt5.5main/5.5/gcc_64/bin/qmake
/usr/BUILD/BuildQt5.5.pre/5.5/gcc_64/bin/qmake
/usr/BUILD/BuildQt5.6beta/5.6/gcc_64/bin/qmake
/usr/BUILD/BuildQt5.5rc/5.5/gcc_64/bin/qmake
/usr/bin/qmake
ATM, 'which qmake' gives /usr/BUILD/BuildQt5.5.1/5.5/gcc_64/bin/qmake.
Sure, it is linux, but it should be alike on windows too.
> But even if it is not possible to call cmake with only these two paths,
> then it should be possible to write a batch file with a monster cmake
> command line containing all ~40 paths. Then it would be easy to do a
> clean build of unpacked sources without relying on cached cmake
> information from previous builds.
>
> > So I still think that creating a new git branch and copying the files
> > from the tar there is the quickest and also safest way - no need to
> > fiddle around with any path.
>
> Here I strongly disagree. By doing this, you have no control over the
> information from the previous builds that is in the cmake cache.
> Therefore it is never sure whether such a build is reproducible (e.g. if
> you re-used the directory to build from git again).
>
> IMO, we should not release any binary that was built in this way.
> Instead we should find a different solution which ensures a 100%
> reproducible build, like we do have for all other platforms.
>
+1
> Georg
Kornel
signature.asc
Description: This is a digitally signed message part.
