The cache needs to be deleted (as you discovered already).
I'll push a script which deletes the complete build dir, cleanest way.
For now I also need the info about Qt 5. What is the expected build
target for beta1? My time is limited and I have to focus on one Qt
version. I installed Qt 5.6 beta for mingw and mingw itself. Is this the
way I should go?
That depends whether you want to learn mingw or not. Concerning qt 5.6 I
Nothing really to learn, just install Qt and use the default paths.
belive the release dates Scott sent do pretty much rule it out (it will be
finished too late), so the question is whether qt 5.5 works wel enough on
windows.
As usual LyX would be late anyway, just lets wait for 5.6.0 when
releasing the Windows installer.
Can you please explain which errors you see (or fear to see) if not
building from the tar ball only?
I need to run CMake again spending half an hour to setup all the many
paths there. This sucks. With a new branch I work in the same directory
as always.
Don't touch the committed build batch file ever. All dirs should be
fixed, and the rest should be relative. I'll prepare a script, which
produces a running LyX version which should be uses by NSIS.
The scripts will only require a dir where the deps saved.
Sorry, I still do not understand. Which paths need to be setup? What takes
He talks about the development/cmake/build* scripts, full with pathes.
long (a manual step or some program that runs)? When I run cmake on linux on
a freshly unpacked source tree I do not need to setup any path, and running
cmake is very fast. It should be possible to do the same on windows. For
reference, here is my procedure as pseudocode:
- unpack source in srcdir
- make build directory builddir
- copy build script to srcdir (this is the equivalent of your build.bat. I
can only think of one path that might need to be adjusted in this script:
The path to the cmake installation (if cmake is not in the system PATH
anyway).
- go to builddir
- call build script
No path adjustments are needed. Which step of this procedure would look
different in your case?
This is very important, because building from the
unpacked tar ball is the only way to ensure that the built executable is
built from the correct sources and without any possible local change. Do
you remember the problem with one of the alphas where much time was
wasted because the installer was not built from unmodified alpha sources?
As I wrote, I make mistakes. I did not had much time to test the alpha
installer. Normally I have at least a day and can check on 4 different
PCs and the buggy installer would have been uncovered.
Everybody makes mistakes. Therefore it is so important to design the
workflow in such a way that the chances for making mistakes are minimized.
If you mix parts from git and parts from a source archive, the chances for
making mistakes are much higher.
Georg
