Re: Questions for Uwe once you are back

[Uwe Stöhr]

Am 19.01.2016 um 23:31 schrieb Peter Kümmel:


setting LYX_BUILD could be done at any time.

And each run ensures LYX_BUILD exists, then removed LYX_BUILD and then
creates it again:

mkdir %LYX_BUILD%
rmdir /s/q %LYX_BUILD%
mkdir %LYX_BUILD%

So  LYX_BUILD is always empty at the beginning.


OK, that this went wrong was due to my write restrictions I set for my 
Git folder as I wrote. It works now.


Besides this, using your script I see many missing files:

-- Building with USE_HUNSPELL
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of ptrdiff_t
-- Check size of ptrdiff_t - done
-- Check size of sig_atomic_t
-- Check size of sig_atomic_t - done
-- Check size of size_t
-- Check size of size_t - done
-- Check size of wchar_t
-- Check size of wchar_t - done
-- Check size of wint_t
-- Check size of wint_t - done
-- Check size of long long int
-- Check size of long long int - done
-- Check size of unsigned long long int
-- Check size of unsigned long long int - done
-- Check size of _Bool
-- Check size of _Bool - failed
-- Looking for include file alloca.h
-- Looking for include file alloca.h - not found
-- Looking for include file dlfcn.h
-- Looking for include file dlfcn.h - not found
-- Looking for include file inttypes.h
-- Looking for include file inttypes.h - not found
-- Looking for include file mach-o/dyld.h
-- Looking for include file mach-o/dyld.h - not found
-- Looking for include file memory.h
-- Looking for include file memory.h - found
-- Looking for include file search.h
-- Looking for include file search.h - found
-- Looking for include file stdlib.h
-- Looking for include file stdlib.h - found
-- Looking for include file strings.h
-- Looking for include file strings.h - not found
-- Looking for include file string.h
-- Looking for include file string.h - found
-- Looking for include file sys/bitypes.h
-- Looking for include file sys/bitypes.h - not found
-- Looking for include file sys/inttypes.h
-- Looking for include file sys/inttypes.h - not found
-- Looking for include file sys/param.h
-- Looking for include file sys/param.h - not found
-- Looking for include file sys/socket.h
-- Looking for include file sys/socket.h - not found
-- Looking for include file sys/stat.h
-- Looking for include file sys/stat.h - found
-- Looking for include file sys/time.h
-- Looking for include file sys/time.h - not found
-- Looking for include file unistd.h
-- Looking for include file unistd.h - not found...

Am I doing something wrong?


Could you nevertheless please look at the CMake bugs:
http://www.lyx.org/trac/ticket/9927
so that others won't have the same problems as I had?


You mean, these flags should be automatically enabled by cmake without
the need to pass them as argument when calling cmake?


Yes.
And and the bug with CMAKE_INSTALL_PREFIX should be fixed. This cost me 
several hours until I figured it out.


many thanks and best regards
Uwe

Re: Questions for Uwe once you are back

[Kornel Benko]

Am Donnerstag, 21. Januar 2016 um 00:30:26, schrieb Uwe Stöhr 
> Am 19.01.2016 um 23:31 schrieb Peter Kümmel:
> 
> > setting LYX_BUILD could be done at any time.
> >
> > And each run ensures LYX_BUILD exists, then removed LYX_BUILD and then
> > creates it again:
> >
> > mkdir %LYX_BUILD%
> > rmdir /s/q %LYX_BUILD%
> > mkdir %LYX_BUILD%
> >
> > So  LYX_BUILD is always empty at the beginning.
> 
> OK, that this went wrong was due to my write restrictions I set for my 
> Git folder as I wrote. It works now.
> 
> Besides this, using your script I see many missing files:
> 
> -- Building with USE_HUNSPELL
> -- Looking for sys/types.h
> -- Looking for sys/types.h - found
> -- Looking for stdint.h
> -- Looking for stdint.h - found
> -- Looking for stddef.h
> -- Looking for stddef.h - found
> -- Check size of ptrdiff_t
> -- Check size of ptrdiff_t - done
> -- Check size of sig_atomic_t
> -- Check size of sig_atomic_t - done
> -- Check size of size_t
> -- Check size of size_t - done
> -- Check size of wchar_t
> -- Check size of wchar_t - done
> -- Check size of wint_t
> -- Check size of wint_t - done
> -- Check size of long long int
> -- Check size of long long int - done
> -- Check size of unsigned long long int
> -- Check size of unsigned long long int - done
> -- Check size of _Bool
> -- Check size of _Bool - failed
> -- Looking for include file alloca.h
> -- Looking for include file alloca.h - not found
> -- Looking for include file dlfcn.h
> -- Looking for include file dlfcn.h - not found
> -- Looking for include file inttypes.h
> -- Looking for include file inttypes.h - not found
> -- Looking for include file mach-o/dyld.h
> -- Looking for include file mach-o/dyld.h - not found
> -- Looking for include file memory.h
> -- Looking for include file memory.h - found
> -- Looking for include file search.h
> -- Looking for include file search.h - found
> -- Looking for include file stdlib.h
> -- Looking for include file stdlib.h - found
> -- Looking for include file strings.h
> -- Looking for include file strings.h - not found
> -- Looking for include file string.h
> -- Looking for include file string.h - found
> -- Looking for include file sys/bitypes.h
> -- Looking for include file sys/bitypes.h - not found
> -- Looking for include file sys/inttypes.h
> -- Looking for include file sys/inttypes.h - not found
> -- Looking for include file sys/param.h
> -- Looking for include file sys/param.h - not found
> -- Looking for include file sys/socket.h
> -- Looking for include file sys/socket.h - not found
> -- Looking for include file sys/stat.h
> -- Looking for include file sys/stat.h - found
> -- Looking for include file sys/time.h
> -- Looking for include file sys/time.h - not found
> -- Looking for include file unistd.h
> -- Looking for include file unistd.h - not found...
> 
> Am I doing something wrong?

This is not about missing header files. We are checking which files exist on 
this platform,
so that we set the appropriate preprocessor variable right.

> >> Could you nevertheless please look at the CMake bugs:
> >> http://www.lyx.org/trac/ticket/9927
> >> so that others won't have the same problems as I had?
> >
> > You mean, these flags should be automatically enabled by cmake without
> > the need to pass them as argument when calling cmake?
> 
> Yes.
> And and the bug with CMAKE_INSTALL_PREFIX should be fixed. This cost me 
> several hours until I figured it out.
> 
> many thanks and best regards
> Uwe

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: Questions for Uwe once you are back

[Peter Kümmel]

Am 19.01.2016 um 22:09 schrieb Uwe Stöhr:

Am 19.01.2016 um 17:15 schrieb Peter Kümmel:


I'll move them again out of the source tree.


But then users might have a problem. For example my git older for master
is D:\LyXGit\Master. It is forbidden to create a new folder in
D:\LyXGit to assure that no folders can be deleted there.


But this is only a special setting on your system.


(E.g. that due to a bug

or whatever D:\LyXGit\Master is deleted.) Within master one can of
course write. I wrote this once somewhere and that is why I set up my
git folder this way.

But OK, your decision.


- I also added
   RMDIR /S /Q %LYX_SOURCE%\build-result-5-2010
   to assure a clean rebuild. Otherwise files that were removed or
   renamed in Git or for a new LyX release could still be in the
LYX_INSTALLED folder.


This was already there.


setting LYX_BUILD could be done at any time.


And each run ensures LYX_BUILD exists, then removed LYX_BUILD and then 
creates it again:


mkdir %LYX_BUILD%
rmdir /s/q %LYX_BUILD%
mkdir %LYX_BUILD%

So  LYX_BUILD is always empty at the beginning.




But at the wrong position. It must be before
set LYX_BUILD=%LYX_SOURCE%\..\build-result-5-2010

Otherwise you get an error when compiling LyX with your script the
second time. because when executing the script the second time the
folder build-result-5-2010 already exists so the creation of it fails.
Th result is that LyX is then built inside the CMake folder and lots of
warnings - things that newbies won't understand and that is not the
desired behavior.
Just execute the script twice to the the problem.

Therefore please leave RMDIR before set LYX_BUILD.

--

Could you nevertheless please look at the CMake bugs:
http://www.lyx.org/trac/ticket/9927
so that others won't have the same problems as I had?


You mean, these flags should be automatically enabled by cmake without 
the need to pass them as argument when calling cmake?




many thanks and best regards
Uwe

Re: Questions for Uwe once you are back

[Stephan Witt]

Am 19.01.2016 um 22:09 schrieb Uwe Stöhr :
> 
> Am 19.01.2016 um 17:15 schrieb Peter Kümmel:
> 
>> I'll move them again out of the source tree.
> 
> But then users might have a problem. For example my git older for master is 
> D:\LyXGit\Master. It is forbidden to create a new folder in
> D:\LyXGit
> to assure that no folders can be deleted there. (E.g. that due to a bug or 
> whatever D:\LyXGit\Master is deleted.) Within master one can of course write. 
> I wrote this once somewhere and that is why I set up my git folder this way.

Then I propose to make this location a parameter too. It really shouldn’t be 
inside the git repository.

Stephan

Re: Questions for Uwe once you are back

[Uwe Stöhr]

Am 19.01.2016 um 17:15 schrieb Peter Kümmel:


I'll move them again out of the source tree.


But then users might have a problem. For example my git older for master 
is D:\LyXGit\Master. It is forbidden to create a new folder in

D:\LyXGit
to assure that no folders can be deleted there. (E.g. that due to a bug 
or whatever D:\LyXGit\Master is deleted.) Within master one can of 
course write. I wrote this once somewhere and that is why I set up my 
git folder this way.


But OK, your decision.


- I also added
   RMDIR /S /Q %LYX_SOURCE%\build-result-5-2010
   to assure a clean rebuild. Otherwise files that were removed or
   renamed in Git or for a new LyX release could still be in the
LYX_INSTALLED folder.


This was already there.


But at the wrong position. It must be before
set LYX_BUILD=%LYX_SOURCE%\..\build-result-5-2010

Otherwise you get an error when compiling LyX with your script the 
second time. because when executing the script the second time the 
folder build-result-5-2010 already exists so the creation of it fails. 
Th result is that LyX is then built inside the CMake folder and lots of 
warnings - things that newbies won't understand and that is not the 
desired behavior.

Just execute the script twice to the the problem.

Therefore please leave RMDIR before set LYX_BUILD.

--

Could you nevertheless please look at the CMake bugs:
http://www.lyx.org/trac/ticket/9927
so that others won't have the same problems as I had?

many thanks and best regards
Uwe

Re: Questions for Uwe once you are back

[Uwe Stöhr]

Am 19.01.2016 um 22:36 schrieb Stephan Witt:


I wrote this once somewhere and that is why I set up my git folder this way.


I meant I read this somewhere.


Then I propose to make this location a parameter too. It really shouldn’t be 
inside the git repository.


OK.

regards Uwe

Re: Questions for Uwe once you are back

[Peter Kümmel]

Am 19.01.2016 um 02:24 schrieb Uwe Stöhr:

Am 18.01.2016 um 10:18 schrieb Peter Kümmel:


Maybe there is still a Qt 4 qmake.exe in PATH.


No, the solution are path changes:

- Qt is installed here in
   C:\Qt\Qt5-5-1-2010\5.5\msvc2010\bin


Ah, this explains all problems!



   not in
   C:\Qt\Qt5.5.1-2010\5.5\msvc2010\bin
   (don't know why, I could change that if you prefer)

- set LYX_BUILD=%LYX_SOURCE%\build-result-5-2010
   instead of
   set LYX_BUILD=%LYX_SOURCE%\..\build-result-5-2010
   (this quit the build operations because the folder could not be created)

- set GNUWIN32_DIR=%LYX_SOURCE%\lyx-windows-deps-msvc2010
   instead of
   set GNUWIN32_DIR=%LYX_SOURCE%\..\lyx-windows-deps-msvc2010
   (same issue as above)


I'll move them again out of the source tree.



- I also added
   RMDIR /S /Q %LYX_SOURCE%\build-result-5-2010
   to assure a clean rebuild. Otherwise files that were removed or
   renamed in Git or for a new LyX release could still be in the
LYX_INSTALLED folder.


This was already there.



With these changes your script works for me. Also the merged build works.

To avoid confusions and to re-enable myself to build devel versions of
LyX 2.2 I restored my script in Git and upload your version with my
changes as
"build5-2010-installer"
to clarify that this is the one-click file to build LyX for an installer.

I removed the now 2 unused build scripts.

I hope that this is fine for you. Feel free to change something in the
one-click script and I will change my paths accordingly.


OK.

Many thanks,
Peter




regards Uwe

Re: Questions for Uwe once you are back

[Uwe Stöhr]

 From: Peter KümmelSent: Montag, 18. Januar 2016 03:26‎> Do you mean you have to specify the Qt pathes in the installer script?No, in CMake as I wrote. My Script works fine.Regards Uwe 

Re: Questions for Uwe once you are back

[Peter Kümmel]

Am 18. Januar 2016 09:20:32 MEZ, schrieb "Uwe Stöhr" :
>
>
>From: Peter Kümmel
>
>Sent: Montag, 18. Januar 2016 03:26‎
>
>
>> Do you mean you have to specify the Qt pathes in the installer
>script?
>
>
>No, in CMake as I wrote. My Script works fine.
>
>
>Regards Uwe 

Maybe there is still a Qt 4 qmake.exe in PATH.

Re: Questions for Uwe once you are back

[Uwe Stöhr]

Am 18.01.2016 um 10:18 schrieb Peter Kümmel:


Maybe there is still a Qt 4 qmake.exe in PATH.


No, the solution are path changes:

- Qt is installed here in
  C:\Qt\Qt5-5-1-2010\5.5\msvc2010\bin
  not in
  C:\Qt\Qt5.5.1-2010\5.5\msvc2010\bin
  (don't know why, I could change that if you prefer)

- set LYX_BUILD=%LYX_SOURCE%\build-result-5-2010
  instead of
  set LYX_BUILD=%LYX_SOURCE%\..\build-result-5-2010
  (this quit the build operations because the folder could not be created)

- set GNUWIN32_DIR=%LYX_SOURCE%\lyx-windows-deps-msvc2010
  instead of
  set GNUWIN32_DIR=%LYX_SOURCE%\..\lyx-windows-deps-msvc2010
  (same issue as above)

- I also added
  RMDIR /S /Q %LYX_SOURCE%\build-result-5-2010
  to assure a clean rebuild. Otherwise files that were removed or
  renamed in Git or for a new LyX release could still be in the 
LYX_INSTALLED folder.


With these changes your script works for me. Also the merged build works.

To avoid confusions and to re-enable myself to build devel versions of 
LyX 2.2 I restored my script in Git and upload your version with my 
changes as

"build5-2010-installer"
to clarify that this is the one-click file to build LyX for an installer.

I removed the now 2 unused build scripts.

I hope that this is fine for you. Feel free to change something in the 
one-click script and I will change my paths accordingly.


regards Uwe

Re: Questions for Uwe once you are back

[Peter Kümmel]

Am 18. Januar 2016 00:56:50 MEZ, schrieb "Uwe Stöhr" :
>Am 15.01.2016 um 22:33 schrieb Georg Baum:
>
>> 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).
>
>OK, now with Qt 5 there are only 6 Qt paths to be specified. But I
>think 
>that this can still be reduced to one, since all Qt installations on 
>Windows have the same structure. So it should be sufficient to specify 
>only the path to the qmake.exe and then CMake has enough info to find 
>the rest.
>Peter, could you perhaps do this like you did for the mingw build?
>
>To please Georg, I will build in future LyX by compiling the source 
>files in a separate folder.

This is not only to please Georg. This is essential for serious software 
development.

>
>regards Uwe

Re: Questions for Uwe once you are back

[Uwe Stöhr]

Am 15.01.2016 um 22:33 schrieb Georg Baum:


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).


OK, now with Qt 5 there are only 6 Qt paths to be specified. But I think 
that this can still be reduced to one, since all Qt installations on 
Windows have the same structure. So it should be sufficient to specify 
only the path to the qmake.exe and then CMake has enough info to find 
the rest.

Peter, could you perhaps do this like you did for the mingw build?

To please Georg, I will build in future LyX by compiling the source 
files in a separate folder.


regards Uwe

Re: Questions for Uwe once you are back

[Peter Kümmel]

Am 18. Januar 2016 00:56:50 MEZ, schrieb "Uwe Stöhr" :
>Am 15.01.2016 um 22:33 schrieb Georg Baum:
>
>> 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).
>
>OK, now with Qt 5 there are only 6 Qt paths to be specified. But I
>think 
>that this can still be reduced to one, since all Qt installations on 
>Windows have the same structure. So it should be sufficient to specify 
>only the path to the qmake.exe and then CMake has enough info to find 
>the rest.
>Peter, could you perhaps do this like you did for the mingw build?
>
>To please Georg, I will build in future LyX by compiling the source 
>files in a separate folder.
>
>regards Uwe

Do you mean you have to specify the Qt pathes in the installer script? Where 
you list the Dll which needs to be copied from c:\Qt into the installer? Then 
your are right, this must be done manually for a msvc build. Only when building 
with mingw all needed dlls are copied automatically into the bin dir.

But again, to build only absolute no Qt pathes should be adjusted anywhere. 

Re: Questions for Uwe once you are back

[Peter Kümmel]

Am 15.01.2016 um 22:33 schrieb Georg Baum:


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.


Reading this I would say we should not release any installer with a LyX 
version build with msvc.


Uwe have you the time to build a installer with a mingw build?

If not maybe someone else finds the time, building native on Windows has 
become much simpler for Linux users:


Windows 10 .iso files are now available and it is easy to install it in 
a virtual box. No Windows keys are needed while installing and all works 
without any "key activation".





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

Re: Questions for Uwe once you are back

[Peter Kümmel]

Am 15.01.2016 um 22:39 schrieb Georg Baum:

Peter Kümmel wrote:


I also don't see a problem to build from a clean git repository.
Only thing I would ensure is to "sit" on tagged release.


I agree that building from a clean git directory is not a problem concerning
the resulting build or reproducibility.

There is however one difference between building from a git tag and from the
corresponding source tar ball (which is not the main topic of this thread):
If you build from git you do not check that the tar ball is complete. In
theory, completeness of the tar ball is checked by "make distcheck", but it
does not take files into account that are only needed for windows (e.g. it
would not find whether a file from 3rdparty is missing).


I assume the tar could only be complete for an installation on Linux.

For Windows Uwe uploaded a ~200 MB zip needed to build the Windows 
installer, these files we will never pack into the tar.


On Windows it would only be possible to build a correct LyX binary with 
all the docs/translations (which I hope is already done by the build 
bot) or the recently added mingw.bat script.





Georg

Re: Questions for Uwe once you are back

[Peter Kümmel]

Am 15.01.2016 um 16:19 schrieb Stephan Witt:



Am 15.01.2016 um 15:48 schrieb Peter Kümmel :



Am 15.01.2016 um 15:01 schrieb Stephan Witt:

Am 15.01.2016 um 14:41 schrieb Peter Kümmel :


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. 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? If that would be the case how can people work with git
in their jobs?


I also don't see a problem to build from a clean git repository.
Only thing I would ensure is to "sit" on tagged release.


Sorry, I sent it too early…

I think there is some misunderstanding here. You’re not talking of the
same use pattern of git.

I think it should go like this:

The git-repository checkout is the source directory.
The build directory should always be outside the source directory.
A clean build starts with removing the build directory completely.


Sure, the git tree should not be touched, and the build should be in an
build directory; I never tough some does in-source builds.


Touching the git tree was the start of the discussion. See above.


Seems, I missed the point.



Stephan

Re: Questions for Uwe once you are back

[Peter Kümmel]

Am 13.01.2016 um 00:21 schrieb Uwe Stöhr:

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.


Uwe, why do you waste you time with such a msvc2010 fiddling?
Why do you not use MinGW builds (your own or the one from the bot?
It would save you much time. You only would have to update the Installer 
nsi scripts a bit.





Georg

Re: Questions for Uwe once you are back

[Scott Kostyshak]

On Sat, Jan 16, 2016 at 12:13:54PM +0100, Peter Kümmel wrote:
> 
> Am 15.01.2016 um 22:33 schrieb Georg Baum:
> >
> >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.
> 
> Reading this I would say we should not release any installer with a LyX
> version build with msvc.

From what I understand, this issue can be solved with MSVC. I think
there is interest in helping Uwe improve the process.

> Uwe have you the time to build a installer with a mingw build?

Indeed this would be nice. I'm not sure Uwe has the time though and no
one else seems to want to do this work.

Scott


signature.asc
Description: PGP signature

Re: Questions for Uwe once you are back

[Scott Kostyshak]

On Sat, Jan 16, 2016 at 12:02:52PM +0100, Peter Kümmel wrote:
> >Am 13.01.2016 um 00:21 schrieb Uwe Stöhr:
> >>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.
> 
> Uwe, why do you waste you time with such a msvc2010 fiddling?

From what I understand, he does this because it works for him and he
doesn't have that much time.

> Why do you not use MinGW builds (your own or the one from the bot?
> It would save you much time. You only would have to update the Installer nsi
> scripts a bit.

If it really is this easy, then hopefully someone else can step up to do
this.

Scott


signature.asc
Description: PGP signature

Re: Questions for Uwe once you are back

[Stephan Witt]

Am 15.01.2016 um 14:41 schrieb Peter Kümmel :
> 
> 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. 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? If that would be the case how can people work with git
>> in their jobs?
> 
> I also don't see a problem to build from a clean git repository.
> Only thing I would ensure is to "sit" on tagged release.

Sorry, I sent it too early…

I think there is some misunderstanding here. You’re not talking of the
same use pattern of git.

I think it should go like this:

The git-repository checkout is the source directory.
The build directory should always be outside the source directory.
A clean build starts with removing the build directory completely.

To automate builds and or make builds reproducible the use of build scripts
is good practice. There the build directory cleanup and passing of locally
adapted parameter values can be placed.

To make a release build you start from the tar-ball instead of the 
git-checkout as source directory. The rest is the same. The build
process is only different in the location of the source directory.

Stephan

> 
>> 
>>> 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?
>> 
>>> 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.
>> 
>> regards Uwe

Re: Questions for Uwe once you are back

[Peter Kümmel]

Am 15.01.2016 um 15:01 schrieb Stephan Witt:

Am 15.01.2016 um 14:41 schrieb Peter Kümmel :


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. 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? If that would be the case how can people work with git
in their jobs?


I also don't see a problem to build from a clean git repository.
Only thing I would ensure is to "sit" on tagged release.


Sorry, I sent it too early…

I think there is some misunderstanding here. You’re not talking of the
same use pattern of git.

I think it should go like this:

The git-repository checkout is the source directory.
The build directory should always be outside the source directory.
A clean build starts with removing the build directory completely.


Sure, the git tree should not be touched, and the build should be in an
build directory; I never tough some does in-source builds.



To automate builds and or make builds reproducible the use of build scripts
is good practice. There the build directory cleanup and passing of locally
adapted parameter values can be placed.

To make a release build you start from the tar-ball instead of the
git-checkout as source directory. The rest is the same. The build
process is only different in the location of the source directory.

Stephan






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?


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.

regards Uwe

Re: Questions for Uwe once you are back

[Stephan Witt]

Am 15.01.2016 um 14:41 schrieb Peter Kümmel :
> 
> 
> 
> 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. 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? If that would be the case how can people work with git
>> in their jobs?
> 
> I also don't see a problem to build from a clean git repository.
> Only thing I would ensure is to "sit" on tagged release.

I think there is some misunderstanding here. You’re not talking of the
same use pattern of git.

I think it should go like this:

The git-repository checkout is the source directory.
The build directory should always be outside the source directory.
A clean build starts with removing the build directory completely.

To automate builds and or make builds reproducible the use of build scripts
is good practice. There the build directory cleanup and passing of locally
adapted parameter values can be placed.

My 2 cents.

Stephan

> 
>> 
>>> 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?
>> 
>> > 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.
>> 
>> regards Uwe

Re: Questions for Uwe once you are back

[Peter Kümmel]

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. 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? If that would be the case how can people work with git
in their jobs?


I also don't see a problem to build from a clean git repository.
Only thing I would ensure is to "sit" on tagged release.




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?

 > 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.

regards Uwe

Re: Questions for Uwe once you are back

[Stephan Witt]

> Am 15.01.2016 um 15:48 schrieb Peter Kümmel :
> 
> 
> 
> Am 15.01.2016 um 15:01 schrieb Stephan Witt:
>> Am 15.01.2016 um 14:41 schrieb Peter Kümmel :
>>> 
>>> 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. 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? If that would be the case how can people work with git
 in their jobs?
>>> 
>>> I also don't see a problem to build from a clean git repository.
>>> Only thing I would ensure is to "sit" on tagged release.
>> 
>> Sorry, I sent it too early…
>> 
>> I think there is some misunderstanding here. You’re not talking of the
>> same use pattern of git.
>> 
>> I think it should go like this:
>> 
>> The git-repository checkout is the source directory.
>> The build directory should always be outside the source directory.
>> A clean build starts with removing the build directory completely.
> 
> Sure, the git tree should not be touched, and the build should be in an
> build directory; I never tough some does in-source builds.

Touching the git tree was the start of the discussion. See above.

Stephan

Re: Questions for Uwe once you are back

[Georg Baum]

Peter Kümmel wrote:

> I also don't see a problem to build from a clean git repository.
> Only thing I would ensure is to "sit" on tagged release.

I agree that building from a clean git directory is not a problem concerning 
the resulting build or reproducibility.

There is however one difference between building from a git tag and from the 
corresponding source tar ball (which is not the main topic of this thread): 
If you build from git you do not check that the tar ball is complete. In 
theory, completeness of the tar ball is checked by "make distcheck", but it 
does not take files into account that are only needed for windows (e.g. it 
would not find whether a file from 3rdparty is missing).


Georg

Re: Questions for Uwe once you are back

[Georg Baum]

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

Re: Questions for Uwe once you are back

[Uwe Stöhr]

Am 14.01.2016 um 02:22 schrieb Uwe Stöhr:


Am 13.01.2016 um 01:20 schrieb Peter Kümmel:


Plain building should work now. But i dont know what comes after that,
to get a real installer.


- Download the installer source file:

http://ftp.lyx.de/LyX%202.2.0-test/LyXPackageComplete220-test.zip.filepart


Please use this new file instead:
http://ftp.lyx.de/LyX%202.2.0-test/LyXPackageComplete220-test.zip

I fixed there some bugs and added necessary files.

regards Uwe

Re: Questions for Uwe once you are back

[Kornel Benko]

Am Donnerstag, 14. Januar 2016 um 23:32:08, 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.

I think, Georg meant that reusing the same build directory for different 
configurations
is error prone.
The minimum here would be to remove CMakeCache.txt from the build dir.

> 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. 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? If that would be the case how can people work with git 
> in their jobs?
> 
> > 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?

Again, he means same build dir for different builds. In this sense, the 100% 
would get my +1.

>  > 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.
> 
> regards Uwe

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: Questions for Uwe once you are back

[Uwe Stöhr]

Am 14.01.2016 um 18:03 schrieb Guenter Milde:


If Ignacio give his OK, then fine with me.


How do I find out?


Please send him an email (CCed him). He is currently translating the 
docs and he uses Spanish LyX for daily work.



Not necessary but helpfull. It would make the documents more "robust":

- a user could try out compilation with Xe/LuaTeX and non-TeX fonts without
   tripping over the "missing character error" and the need to search for a
   suitable font.


You know my opinion. the docs are to describe LyX's features. Thus they 
are designed to read them in LyX or to press the view button and read 
them as PDF. They are NOT designed to change them. If you do it is your 
business.
Note that on Windows you can even not modify the doc files because one 
cannot modify the install folder.



Setting alternative system fonts in the source docs will help the "secondary
use" without affectiong the "primary use".


Well, what is a system font? Every system has its own system fonts. Win 
Vista uses other fonts than Win 7 or Win 10. I read that e.g. Times New 
Roman of Win Vista covers other (less) chars than the version in Win 10.
I don't see a reason why we need to invest much time to keep the 
UserGuide compilable for fonts and settings a user might use/change on 
systems we don't know.


regards Uwe

Re: Questions for Uwe once you are back

[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. 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? If that would be the case how can people work with git 
in their jobs?



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?


> 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.


regards Uwe

Re: Questions for Uwe once you are back

[Georg Baum]

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.


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.



Georg

Re: Questions for Uwe once you are back

[Kornel Benko]

Am Donnerstag, 14. Januar 2016 um 21:22:43, schrieb Georg Baum 

> 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.

Re: Questions for Uwe once you are back

[Guenter Milde]

Dear Uwe,

On 2016-01-10, Uwe Stöhr wrote:


>> GM1: could we add a line
>>   \@ifpackageloaded{fontspec}{\unaccentedoperators}{}
>>   to the user-preamble of doc/es/UserGuide.lyx?

>>   This would work around a bug in babel-spanish preventing
>>   compilation with non-TeX fonts without affecting the default
>>   pdflatex output.

> If Ignacio give his OK, then fine with me.

How do I find out?

>> GM2: may we define alternative "non-TeX fonts" in the manuals containing
>>  characters missing in the default LatinModern Unicode fonts?

>>  Again, this would help compilation with non-TeX fonts without affecting
>>  the default output.

> Is this really necessary?

Not necessary but helpfull. It would make the documents more "robust":

- a user could try out compilation with Xe/LuaTeX and non-TeX fonts without
  tripping over the "missing character error" and the need to search for a
  suitable font.
  
> I mean the userGuide is there to describe the features of LyX. 

This is the main purpose of the userGuide. 

In addition, all documents shipped with LyX are also starting points for
exploration and samples in the export tests.

Setting alternative system fonts in the source docs will help the "secondary
use" without affectiong the "primary use".

Günter

Re: Questions for Uwe once you are back

[Uwe Stöhr]

Am 13.01.2016 um 01:20 schrieb Peter Kümmel:


Plain building should work now. But i dont know what comes after that, to get a 
real installer.


- Download the installer source file:

http://ftp.lyx.de/LyX%202.2.0-test/LyXPackageComplete220-test.zip.filepart

- unzip it and follow the instructions in the Readme.txt file

- to build the installer for a new LyX version, simply copy the content 
of the folder "LYX_INSTALLED" (is in your build tree after a successful 
compilation) to the subfolder "LyX" of the installer source. Finally run 
the *.nsi scripts by right-clicking on them.


regards Uwe

Re: Questions for Uwe once you are back

[Peter Kümmel]

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

Re: Questions for Uwe once you are back

[Georg Baum]

Uwe Stöhr wrote:

> Am 11.01.2016 um 21:22 schrieb Georg Baum:
> 
>> I don't know whether he got them from you or directly from the original
>> download pages, but this does not matter. What matters is that you get a
>> consistent build and eliminate possible errors if you use these sources
>> (by enabling the 3RDPARTY_BUILD swithc as I wrote in the other message).
> 
> I need a pointer here. There are too many posts I cannot read them all.
> What do I have to do? Adding
> -LYX_3RDPARTY_BUILD=ON
> to my build script does not work:
> 
> CMake Error: The source directory
> "D:/LyXGit/Master/compile-2010/-LYX_3RDPARTY_BUILD=ON" does not exist.
> Specify --help for usage, or press the help button on the CMake GUI.
> 
> Maybe I will have to delete the CMake cache before and then re-run
> Cmake. I'll check this now.

The cache needs to be deleted (as you discovered already).
 
> 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 
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.

>> 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.

Sorry, I still do not understand. Which paths need to be setup? What takes 
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

Re: Questions for Uwe once you are back

[Peter Kümmel]

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?


Yes, that would be great!
It looks like the paths will also not change after the release of 5.6.0
(default is C:\Qt\Qt5.6.0) So I would like to add one .bat script
for the mingw build with most paths hardcoded. Maybe we could even
agree where to put the lyx sources/build dir.

Then lets release a lyx beta MinGW build with the Qt 5.6 beta and
when 5.6 is out just make the the final lyx with the 5.6.0.





Sure. I try to do this but I am a human making mistakes. And the path
handling stuff for the compiler is error-prone as hell. Thus I simply
create a new branch in my git putting there the files from the tar. This
assures that the compilation paths are correct.


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.


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.

regards Uwe

Re: Questions for Uwe once you are back

[Uwe Stöhr]

Am 12.01.2016 um 19:43 schrieb Georg Baum:


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
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.


OK, I will test my 5.5.1 build with MSVC201 thoroughly and report back.

For Qt 5.6 I will use MinGW and not MSVC. Since both are new programs to 
me I think it makes sense to release beta1 with 5.5 if possible if Scott 
agrees.



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.

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.


regards Uwe

Re: Questions for Uwe once you are back

[Uwe Stöhr]

Am 12.01.2016 um 11:23 schrieb Peter Kümmel:


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?


Yes, that would be great!


Hi Peter,

OK, I will try this. Since I never used MinGW I expect some obstacles 
and will contact you. OK?



It looks like the paths will also not change after the release of 5.6.0
(default is C:\Qt\Qt5.6.0) So I would like to add one .bat script
for the mingw build with most paths hardcoded. Maybe we could even
agree where to put the lyx sources/build dir.


Sure. Make a proposal for a path.


Then lets release a lyx beta MinGW build with the Qt 5.6 beta and
when 5.6 is out just make the the final lyx with the 5.6.0.


Would be fine with me but it seems that Qt 5.6 is delayed (just googled 
a bit around)

Scott? What is your opinion?

thanks and regards
Uwe

Re: Questions for Uwe once you are back

[Scott Kostyshak]

On Wed, Jan 13, 2016 at 12:21:52AM +0100, Uwe Stöhr wrote:

> For Qt 5.6 I will use MinGW and not MSVC. Since both are new programs to me
> I think it makes sense to release beta1 with 5.5 if possible if Scott
> agrees.

I do agree with 5.5.1. I just started a new thread for this:
https://www.mail-archive.com/search?l=mid=20160112233211.GA16403%40OptiPlex-9020.ad.ufl.edu

I remember Peter mentioning a preference for 5.6, so I hope to hear
feedback from him on that thread (and hopefully others) before we make a
decision.

Scott


signature.asc
Description: PGP signature

Re: Questions for Uwe once you are back

[Uwe Stöhr]

Am 12.01.2016 um 00:55 schrieb Kornel Benko:


* for hunspell_include_dir I get this path:
D:/LyXGit/Master/3rdparty/hunspell/1.3.3/src
* for iconv_include_dir I get this path:
D:/LyXGit/Master/compile-2010/libiconv/include

This seems wrong to me. I expect that in both cases the files from
D:/LyXGit/Master/3rdparty are taken. and indeed when generating CMake it
tells me that it cannot find iconv.


You are right. Looks like somehow the variable 'UNIX' is set, because for 
windows
the package ICONV should no be searched.
Please try attached patch.


many thanks.
I tried this but I cannot see a difference:

- still
 D:/LyXGit/Master/compile-2010/libiconv/include
 is found by CMake when running it from scratch (which does not exist) 
and not

 D:\LyXGit\Master\3rdparty\libiconv\1.14\include

- in the CMake GUI (CMake 3.4.1) I still cannot click in the path of
  iconv_include_dir
  to change it via a button (with 3 dots) that appears on the right
  side of the path
  (This works for all other paths in CMake.)

2 other CMake issues:

- I think that -LYX_3RDPARTY_BUILD=1 should by default be set in CMake 
when running it from scratch for a new build.


- The LYX_MAN_DIR defaults on Windows to
  /usr/local/man/man1
  which is not a valid path


thanks and regards
Uwe

Re: Questions for Uwe once you are back

[Peter Kümmel]

Am 13. Januar 2016 00:21:52 MEZ, schrieb "Uwe Stöhr" :
>Am 12.01.2016 um 19:43 schrieb Georg Baum:
>
>>> 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
>> 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.
>
>OK, I will test my 5.5.1 build with MSVC201 thoroughly and report back.
>
>For Qt 5.6 I will use MinGW and not MSVC. Since both are new programs
>to 
>me I think it makes sense to release beta1 with 5.5 if possible if
>Scott 
>agrees.
>
>> 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.

The mingw build collects all the qt files with the install rules. No path 
should be manually touched. All missimg should be written down into the cmake 
files.



>
>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.
>
>regards Uwe

Re: Questions for Uwe once you are back

[Peter Kümmel]

My time is limited and I have to focus onone Qt
>>> version. I installed Qt 5.6 beta for mingw and mingw itself. Is this
>the way I should go?
>>
>> Yes, that would be great!
>
>Hi Peter,
>
>OK, I will try this. Since I never used MinGW I expect some obstacles 
>and will contact you. OK?

Sure! Plain building should work now. But i dont know what comes after that, to 
get a real installer. 

>
>> It looks like the paths will also not change after the release of
>5.6.0
>> (default is C:\Qt\Qt5.6.0) So I would like to add one .bat script
>> for the mingw build with most paths hardcoded. Maybe we could even
>> agree where to put the lyx sources/build dir.
>
>Sure. Make a proposal for a path.
>
>> Then lets release a lyx beta MinGW build with the Qt 5.6 beta and
>> when 5.6 is out just make the the final lyx with the 5.6.0.
>
>Would be fine with me but it seems that Qt 5.6 is delayed (just googled
>
>a bit around)
>Scott? What is your opinion?
>
>thanks and regards
>Uwe

Re: Questions for Uwe once you are back

[Uwe Stöhr]

Am 11.01.2016 um 21:22 schrieb Georg Baum:


I don't know whether he got them from you or directly from the original
download pages, but this does not matter. What matters is that you get a
consistent build and eliminate possible errors if you use these sources (by
enabling the 3RDPARTY_BUILD swithc as I wrote in the other message).


I need a pointer here. There are too many posts I cannot read them all.
What do I have to do? Adding
-LYX_3RDPARTY_BUILD=ON
to my build script does not work:

CMake Error: The source directory 
"D:/LyXGit/Master/compile-2010/-LYX_3RDPARTY_BUILD=ON" does not exist.

Specify --help for usage, or press the help button on the CMake GUI.

Maybe I will have to delete the CMake cache before and then re-run 
Cmake. I'll check this now.


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?



Sure. I try to do this but I am a human making mistakes. And the path
handling stuff for the compiler is error-prone as hell. Thus I simply
create a new branch in my git putting there the files from the tar. This
assures that the compilation paths are correct.


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.



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.


regards Uwe

Re: Questions for Uwe once you are back

[Scott Kostyshak]

On Mon, Jan 11, 2016 at 12:45:11AM +0100, Uwe Stöhr wrote:

> My question: what is the plan for LyX 2.2.0: Do we release with Qt 5.6 or
> not? Should I try out its beta version?

My opinion is that we should only use Qt 5.6 for the final LyX 2.1
release if we use Qt 5.6beta for LyX 2.1beta1. From what I understand,
using Qt 5.6beta would be complicated because it does not have the
binaries posted (or maybe it was that it doesn't support MSVC 2010?). Is
this true? If so, then it seems that we can't use 5.6beta for LyX
2.1beta1?

A separate point to consider is that Qt 5.6 is scheduled to be released
February 9th. This is a minimum release date, meaning I would not be
surprised if the final release date is significantly delayed.

I don't know if this is important, but a final point to consider is that
5.6 is a long-term release. It might be nice to keep the whole 2.2.x
series on 5.6.x.

Scott


signature.asc
Description: PGP signature

Re: Questions for Uwe once you are back

[Kornel Benko]

Am Dienstag, 12. Januar 2016 um 00:25:37, schrieb Uwe Stöhr 
> Am 11.01.2016 um 23:50 schrieb Kornel Benko:
>
> > it is -DLYX_3RDPARTY_BUILD=ON added to the call to cmake.
>
> I tried this but it won't work.
>
> What I did now is:
> - delete everything from CMake (cache)
> - run Cmake from scratch
>
> This way found bugs:
>
> * for hunspell_include_dir I get this path:
> D:/LyXGit/Master/3rdparty/hunspell/1.3.3/src
> * for iconv_include_dir I get this path:
> D:/LyXGit/Master/compile-2010/libiconv/include
>
> This seems wrong to me. I expect that in both cases the files from
> D:/LyXGit/Master/3rdparty are taken. and indeed when generating CMake it
> tells me that it cannot find iconv.

You are right. Looks like somehow the variable 'UNIX' is set, because for 
windows
the package ICONV should no be searched.
Please try attached patch.

> besides this: I cannot click behind the path of hunspell_include_dir and
> iconv_include_dir to change their path.
>
> I compiled now anyway and get at first this new error:
>
>GuiBibtex.cpp
> ..\..\..\..\src\frontends\qt4\GuiApplication.cpp(134): fatal error
> C1083: Datei (Include) kann nicht geöffnet werden: "QWinMime": No such
> file or directory
> [D:\LyXGit\Master\compile-2010\src\frontends\qt4\frontend_qt.vcxproj]
>
> This is another CMake bug because I explicitly set to use Qt5 in CMake
> and not Qt4.

Don't be mislead from the qt4-dir. This is OK, 'qt4' should be renamed to 'qt' 
sometime.

> Could you please help me here?
>
> many thanks in advance and regards
> Uwe

Kornel

signature.asc
Description: This is a digitally signed message part.
diff --git a/CMakeLists.txt b/CMakeLists.txt
index f657fd5..0673adb 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -673,7 +673,7 @@ if(LYX_NLS)
 	endif()
 endif()
 
-if(UNIX)
+if(NOT WIN32)
 find_package(ICONV REQUIRED)
 find_package(ZLIB REQUIRED)
 else()

Re: Questions for Uwe once you are back

[Uwe Stöhr]

Am 12.01.2016 um 00:25 schrieb Uwe Stöhr:


   GuiBibtex.cpp
..\..\..\..\src\frontends\qt4\GuiApplication.cpp(134): fatal error
C1083: Datei (Include) kann nicht geöffnet werden: "QWinMime": No such
file or directory
[D:\LyXGit\Master\compile-2010\src\frontends\qt4\frontend_qt.vcxproj]

This is another CMake bug because I explicitly set to use Qt5 in CMake
and not Qt4.


Hmm, I did now nothing else than to re-run CMake without changing 
anything there and now this bug is gone.


regards Uwe

Re: Questions for Uwe once you are back

[Kornel Benko]

Am Montag, 11. Januar 2016 um 23:37:12, schrieb Uwe Stöhr 
> Am 11.01.2016 um 21:22 schrieb Georg Baum:
> 
> > I don't know whether he got them from you or directly from the original
> > download pages, but this does not matter. What matters is that you get a
> > consistent build and eliminate possible errors if you use these sources (by
> > enabling the 3RDPARTY_BUILD swithc as I wrote in the other message).
> 
> I need a pointer here. There are too many posts I cannot read them all.
> What do I have to do? Adding
> -LYX_3RDPARTY_BUILD=ON
> to my build script does not work:

it is -DLYX_3RDPARTY_BUILD=ON added to the call to cmake.
(e.g build5.bat:84 or build5.bat:91)

...

> regards Uwe

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: Questions for Uwe once you are back

[Uwe Stöhr]

Am 11.01.2016 um 23:50 schrieb Kornel Benko:


it is -DLYX_3RDPARTY_BUILD=ON added to the call to cmake.


I tried this but it won't work.

What I did now is:
- delete everything from CMake (cache)
- run Cmake from scratch

This way found bugs:

* for hunspell_include_dir I get this path:
D:/LyXGit/Master/3rdparty/hunspell/1.3.3/src
* for iconv_include_dir I get this path:
D:/LyXGit/Master/compile-2010/libiconv/include

This seems wrong to me. I expect that in both cases the files from 
D:/LyXGit/Master/3rdparty are taken. and indeed when generating CMake it 
tells me that it cannot find iconv.


besides this: I cannot click behind the path of hunspell_include_dir and 
iconv_include_dir to change their path.


I compiled now anyway and get at first this new error:

  GuiBibtex.cpp
..\..\..\..\src\frontends\qt4\GuiApplication.cpp(134): fatal error 
C1083: Datei (Include) kann nicht geöffnet werden: "QWinMime": No such 
file or directory 
[D:\LyXGit\Master\compile-2010\src\frontends\qt4\frontend_qt.vcxproj]


This is another CMake bug because I explicitly set to use Qt5 in CMake 
and not Qt4.


Could you please help me here?

many thanks in advance and regards
Uwe

Re: Questions for Uwe once you are back

[Georg Baum]

Uwe Stöhr wrote:

> Am 10.01.2016 um 22:21 schrieb Scott Kostyshak:
> 
>> G1. Not a question but a prerequisite IMHO: The 2.2.0 release should also
>> build the prerequisite from the sources Peter added, using exactly the
>> same compiler as is used to build LyX.
> 
> It seems the sources Peter added are those I uploaded.

I don't know whether he got them from you or directly from the original 
download pages, but this does not matter. What matters is that you get a 
consistent build and eliminate possible errors if you use these sources (by 
enabling the 3RDPARTY_BUILD swithc as I wrote in the other message).


>> S2. Can you make the installers from *only* the tar ball
> 
> Sure. I try to do this but I am a human making mistakes. And the path
> handling stuff for the compiler is error-prone as hell. Thus I simply
> create a new branch in my git putting there the files from the tar. This
> assures that the compilation paths are correct.

Can you please explain which errors you see (or fear to see) if not building 
from the tar ball only? 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?


Georg

Questions for Uwe once you are back

[Scott Kostyshak]

Hi Uwe,

I hope your trip went OK. Do you have an idea of when you will be able to get
back to LyX development? It would be nice to know so we can get an idea of when
to release beta1. Since we know you are busy, we have aggregated most of our
questions for you into one email.

The following letters refer to the person that asked the question.

G=Georg
R=Richard
S=Scott
GM=Günter

R1. Do we also want to try releasing an installer built with mingw?
(G response: IMO, we only need to release one installer. The mingw and MSVC
builds behave exactly the same (modulo bugs). So the question is rather whether
we do trust MSVC or mingw, and who does the build: If it is Uwe, it will be
MSVC, otherwise it will probably be mingw.

G1. Not a question but a prerequisite IMHO: The 2.2.0 release should also build
the prerequisite from the sources Peter added, using exactly the same compiler
as is used to build LyX.

GM1: could we add a line
 \@ifpackageloaded{fontspec}{\unaccentedoperators}{}
 to the user-preamble of doc/es/UserGuide.lyx?

 This would work around a bug in babel-spanish preventing
 compilation with non-TeX fonts without affecting the default
 pdflatex output.

GM2: may we define alternative "non-TeX fonts" in the manuals containing
 characters missing in the default LatinModern Unicode fonts?

 Again, this would help compilation with non-TeX fonts without affecting
 the default output.

S1. Can you build beta1 installers with both your original way and also using
the mingw build from Peter's build bot? From what I understand, this involves
downloading the zip from:
https://github.com/syntheticpp/LyX-bleeding-edge/archive/LyX-master-win32.zip

S2. Can you make the installers from *only* the tar ball (and not use the git
directory at all)? Note that if there is a technical reason why this is
difficult if you ask on the list I am guessing someone can help.

S3. Richard has been committing updates to po files. Can you confirm that all
translation updates we have received have been merged? Has anyone emailed
updates to you privately?

S4. Can you still reproduce these two tickets?
http://www.lyx.org/trac/ticket/9892
http://www.lyx.org/trac/ticket/9900
If so, do you think they are beta blockers?

Scott


signature.asc
Description: PGP signature

Re: Questions for Uwe once you are back

[Uwe Stöhr]

Am 10.01.2016 um 22:21 schrieb Scott Kostyshak:


I hope your trip went OK.


Hi all,

a happy new year. I am just back so don't expect too much - I have also 
a real life.



Do you have an idea of when you will be able to get
back to LyX development?


Tomorrow.


It would be nice to know so we can get an idea of when
to release beta1. Since we know you are busy, we have aggregated most of our
questions for you into one email.

The following letters refer to the person that asked the question.

G=Georg
R=Richard
S=Scott
GM=Günter

R1. Do we also want to try releasing an installer built with mingw?
(G response: IMO, we only need to release one installer. The mingw and MSVC
builds behave exactly the same (modulo bugs). So the question is rather whether
we do trust MSVC or mingw, and who does the build: If it is Uwe, it will be
MSVC, otherwise it will probably be mingw.


MSVC 2010 compiles fine here with Qt 4.8.x and most probably with Qt 
5.5.1. MSVC 2013 compiles with Qt 5.5.1 but crashes with any file I try 
to open because of a libiconv issue. I will contact Peter to learn what 
he did in the meantime.



G1. Not a question but a prerequisite IMHO: The 2.2.0 release should also build
the prerequisite from the sources Peter added, using exactly the same compiler
as is used to build LyX.


It seems the sources Peter added are those I uploaded.


GM1: could we add a line
  \@ifpackageloaded{fontspec}{\unaccentedoperators}{}
  to the user-preamble of doc/es/UserGuide.lyx?

  This would work around a bug in babel-spanish preventing
  compilation with non-TeX fonts without affecting the default
  pdflatex output.


If Ignacio give his OK, then fine with me.


GM2: may we define alternative "non-TeX fonts" in the manuals containing
  characters missing in the default LatinModern Unicode fonts?

  Again, this would help compilation with non-TeX fonts without affecting
  the default output.


Is this really necessary? I mean the userGuide is there to describe the 
features of LyX. For special things we have special smaller files. So I 
propose to create some like e.g. yx-pic special manual.



S1. Can you build beta1 installers with both your original way and also using
the mingw build from Peter's build bot? From what I understand, this involves
downloading the zip from:
https://github.com/syntheticpp/LyX-bleeding-edge/archive/LyX-master-win32.zip


I will contact him and report back.


S2. Can you make the installers from *only* the tar ball


Sure. I try to do this but I am a human making mistakes. And the path 
handling stuff for the compiler is error-prone as hell. Thus I simply 
create a new branch in my git putting there the files from the tar. This 
assures that the compilation paths are correct.



S3. Richard has been committing updates to po files. Can you confirm that all
translation updates we have received have been merged? Has anyone emailed
updates to you privately?


I'll check.


S4. Can you still reproduce these two tickets?
http://www.lyx.org/trac/ticket/9892


I cannot tell right now.


http://www.lyx.org/trac/ticket/9900


No, see my comment there.

My question: what is the plan for LyX 2.2.0: Do we release with Qt 5.6 
or not? Should I try out its beta version?


regards Uwe