Am 14.01.2016 um 23:32 schrieb Uwe Stöhr:
Am 14.01.2016 um 21:22 schrieb Georg Baum:
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).
I don't understand. It is up to me to decide which branch becomes
active. All other branches and their files are invisible for the
compiler and also for CMake. As I understood it CMake is only
necessary to tell the compiler where and in which order to take the
files from.
Indirectly (via the MSVC project files .sln and .vcxproj) yes. In order
to do so, cmake does run lots of tests. These tests are partly
implemented in the cmake installation, and partly in the LyX sources
(development/cmake). The results of these tests are cached. If you now
re-use an existing cmake cache to build LyX from different sources, then
the contents of the MSVC project files (and therefore the resulting
build) depends on the history of your previous cmake calls, and whether
something was changed in development/cmake in the meantime. If you
ensure that no cached information is re-used then the build is
reprodcible (but you would need to specify the 40 paths again withj your
current way of calling cmake).
I built this way now for about 2 years. Why do I need to take care of
the CMake cache? From where do you know that building from a git
folder is not reproducible?
I did not say that. Building from a git folder is reproducible if you do
it correctly (i.e. deleting all cached information from a previous run).
If that would be the case how can people work with git in their jobs?
Almost all people who work with git (or any other version control
system) on their jobs do have an automated nightly build which does not
need any manual input, and is completely configured by configuration
files, batch files or similar mechanisms. If they don't, they will run
sooner or later into problems (I once knew a software company which did
not have such a build. The company does not exist anymore).
IMO, we should not release any binary that was built in this way.
I don't like your 100% "basta" statements. Building under Win is
obviously a bit different than on Unix. Have you ever tried
TortoiseGit or another Git client under Windows?
No. And I don't need to (but I have lots of experience with building
software under windows). The problem we are discussing has nothing to do
with git. It has something to do with calling cmake in such a way that
the build works, and without the need for manually specifying 40 paths.
> Instead we should find a different solution which ensures a 100%
> reproducible build, like we do have for all other platforms.
How do you control the people? Why do you think I don't care to get a
correct build? When I make a mistake there I will be flooded by user
complaints.
Please do not put words in my mouth that I did not say. I explained why
I think that a different solution to the problem of manually specifying
40 paths for building each new release than the one you choose is
needed. I did not say that you don't care to get a correct build. I
rather think that you overestimate the work which is needed to follow my
proposal, and that you underestimate the problems that can arise from
the current way of building. This is not equal to not caring.
And these problems do exist. The 2.2 alpha is not the first windows
binary that turned out to be built from different sources than
originally thought (http://www.lyx.org/trac/ticket/9878). I remember a
similar issue from several years ago, might be 1.6 or 2.0. This type of
mistakes (which can cost lots of hours or even days of wasted time for
several people) is easy to make with your current approach. It is very
difficult to make with my proposal.
I am willing to help you to get a reproducible, clean build. I am not
willing to waste my time investigating bugs that are caused by
inconsistently built binaries.
Georg
