Re: Staging Branches [REVISED]

[Peter Kümmel]

Am 18. April 2016 22:56:06 MESZ, schrieb Richard Heck <rgh...@lyx.org>:
>On 04/18/2016 04:32 PM, Peter Kümmel wrote:
>> Am 18. April 2016 22:29:51 MESZ, schrieb "Peter Kümmel"
><syntheti...@gmx.net>:
>>> I also think these branches are overkill.
>>>
>>> I would only use master and 2.2. No 2.3, it is so far away that it
>could be in master. 
>>>
>>> 2.2 should be always stable so that at any time a short living 2.2.x
>could be branched until the release is done. After the tag 2.2.x will
>be deleted then.
>>>
>>> Similar to 
>>> https://wiki.qt.io/Branch_Guidelines
>>>
>>> Peter
>> We should already be on 2.2 and not on master, which is the future:
>2.3 
>
>We discussed this sort of option: Branch 2.2.x now and continue
>development towards 2.2.0 there. Then development targeted at 2.3 can
>continue in master. But most people didn't like this option. Most
>importantly, Scott didn't like it, or didn't feel comfortable with it,
>and it's his call.
>
>So master is still what will become 2.2.0, and it is closed except for
>absolutely essential fixes. But people wanted to be able to continue
>development, so that's why we have 2.3-staging.
>
>The other two 2.2.x-staging branches are entirely for book-keeping
>purposes. It is just easier for me to have the various fixes that are
>intended for 2.2.1 and 2.2.2 in git branches rather than to try to keep
>track of them via milestones or keywords or whatever in trac. It's also
>easier for people to backport these fixes around the same time they did
>them than to do it weeks or months later.
>
>We're not really "think[ing] about four stable releases in parallel",
>and certainly I do not expect that the staging branches are going to
>get
>any kind of testing. Once 2.2.x is created, it will get testing, and at
>that point 2.2.1-staging will be merged into it, and then will politely
>disappear. Same, eventually, for 2.2.2-staging.
>
>Richard

But why are there fixes which should go only into 2.2.2 and not into an 
unreleased 2.2.1? 
Peter

Re: Staging Branches [REVISED]

[Peter Kümmel]

Am 18. April 2016 22:29:51 MESZ, schrieb "Peter Kümmel" <syntheti...@gmx.net>:
>Am 18. April 2016 21:28:04 MESZ, schrieb Georg Baum
><georg.b...@post.rwth-aachen.de>:
>>Richard Heck wrote:
>>
>>> We now have three staging branches. These are:
>>> 
>>> 2.3-staging
>>> 2.2.1-staging
>>> 2.2.2-staging
>>
>>That makes 5 active branches in total (please correct me if I
>>misunderstood 
>>something):
>>
>>2.1.x  => will become 2.1.5
>>master => will become 2.2.0
>>2.2.1-staging  => will become 2.2.1
>>2.2.2-staging  => will become 2.2.2
>>2.3-staging=> will become 2.3.0
>>
>>Am I the only one who thinks that this is too much? IMHO this results
>>in a 
>>lot of additional book keeping work that eats from our valuable
>>resources. 
>>In addition, there are the trac keyword problems. Currently it is not 
>>possible to map these branches to trac, if we wanted to do that we'd
>>need 
>>three additional keywords for the staging branches. If we do not add
>>these 
>>keywords then bugs might be closed for the wrong milestone and/or we
>>need 
>>manual work to find out from trac whether a particular bug will be
>>fixed 
>>e.g. for 2.2.1 or not.
>>
>>Such a structure is good for large organizations. It does not make
>>sense for 
>>such a small group of part time developers like us IMHO. We do not
>have
>>the 
>>resources to think about four stable releases in parallel. IMHO we
>>should 
>>concentrate on one branch for 2.2.0 and one for 2.3 development, and
>>refrain 
>>from big refactoring projects in 2.3 until 2.2.1 is out. Nobody will
>>try out 
>>all these different 2.2 branches, so these fixes won't get additional 
>>testing. In the contrary, I believe that they would get more testing
>if
>>they 
>>were all in one 2.3 branch.  Also, I doubt that we can now plan ahead
>>for 
>>2.2.2, these plans are likely to become obsolete. We have a simple
>tool
>>to 
>>schedule bug fixes: Milestones in trac. If we put all bug fixes in the
>>2.3 
>>branch and set the bug milestones it is easy to get a list of all
>fixes
>>that 
>>need backporting.
>>
>>
>>Georg
>
>I also think these branches are overkill.
>
>I would only use master and 2.2. No 2.3, it is so far away that it
>could be in master. 
>
>2.2 should be always stable so that at any time a short living 2.2.x
>could be branched until the release is done. After the tag 2.2.x will
>be deleted then.
>
>Similar to 
>https://wiki.qt.io/Branch_Guidelines
>
>Peter

We should already be on 2.2 and not on master, which is the future: 2.3 

Re: Staging Branches [REVISED]

[Peter Kümmel]

Am 18. April 2016 22:29:51 MESZ, schrieb "Peter Kümmel" <syntheti...@gmx.net>:
>Am 18. April 2016 21:28:04 MESZ, schrieb Georg Baum
><georg.b...@post.rwth-aachen.de>:
>>Richard Heck wrote:
>>
>>> We now have three staging branches. These are:
>>> 
>>> 2.3-staging
>>> 2.2.1-staging
>>> 2.2.2-staging
>>
>>That makes 5 active branches in total (please correct me if I
>>misunderstood 
>>something):
>>
>>2.1.x  => will become 2.1.5
>>master => will become 2.2.0
>>2.2.1-staging  => will become 2.2.1
>>2.2.2-staging  => will become 2.2.2
>>2.3-staging=> will become 2.3.0
>>
>>Am I the only one who thinks that this is too much? IMHO this results
>>in a 
>>lot of additional book keeping work that eats from our valuable
>>resources. 
>>In addition, there are the trac keyword problems. Currently it is not 
>>possible to map these branches to trac, if we wanted to do that we'd
>>need 
>>three additional keywords for the staging branches. If we do not add
>>these 
>>keywords then bugs might be closed for the wrong milestone and/or we
>>need 
>>manual work to find out from trac whether a particular bug will be
>>fixed 
>>e.g. for 2.2.1 or not.
>>
>>Such a structure is good for large organizations. It does not make
>>sense for 
>>such a small group of part time developers like us IMHO. We do not
>have
>>the 
>>resources to think about four stable releases in parallel. IMHO we
>>should 
>>concentrate on one branch for 2.2.0 and one for 2.3 development, and
>>refrain 
>>from big refactoring projects in 2.3 until 2.2.1 is out. Nobody will
>>try out 
>>all these different 2.2 branches, so these fixes won't get additional 
>>testing. In the contrary, I believe that they would get more testing
>if
>>they 
>>were all in one 2.3 branch.  Also, I doubt that we can now plan ahead
>>for 
>>2.2.2, these plans are likely to become obsolete. We have a simple
>tool
>>to 
>>schedule bug fixes: Milestones in trac. If we put all bug fixes in the
>>2.3 
>>branch and set the bug milestones it is easy to get a list of all
>fixes
>>that 
>>need backporting.
>>
>>
>>Georg
>
>I also think these branches are overkill.
>
>I would only use master and 2.2. No 2.3, it is so far away that it
>could be in master. 
>
>2.2 should be always stable so that at any time a short living 2.2.x
>could be branched until the release is done. After the tag 2.2.x will
>be deleted then.
>
>Similar to 
>https://wiki.qt.io/Branch_Guidelines
>
>Peter

We should already be on 2.2 and not on master, which is the future: 2.3 

Re: Staging Branches [REVISED]

[Peter Kümmel]

Am 18. April 2016 21:28:04 MESZ, schrieb Georg Baum 
:
>Richard Heck wrote:
>
>> We now have three staging branches. These are:
>> 
>> 2.3-staging
>> 2.2.1-staging
>> 2.2.2-staging
>
>That makes 5 active branches in total (please correct me if I
>misunderstood 
>something):
>
>2.1.x  => will become 2.1.5
>master => will become 2.2.0
>2.2.1-staging  => will become 2.2.1
>2.2.2-staging  => will become 2.2.2
>2.3-staging=> will become 2.3.0
>
>Am I the only one who thinks that this is too much? IMHO this results
>in a 
>lot of additional book keeping work that eats from our valuable
>resources. 
>In addition, there are the trac keyword problems. Currently it is not 
>possible to map these branches to trac, if we wanted to do that we'd
>need 
>three additional keywords for the staging branches. If we do not add
>these 
>keywords then bugs might be closed for the wrong milestone and/or we
>need 
>manual work to find out from trac whether a particular bug will be
>fixed 
>e.g. for 2.2.1 or not.
>
>Such a structure is good for large organizations. It does not make
>sense for 
>such a small group of part time developers like us IMHO. We do not have
>the 
>resources to think about four stable releases in parallel. IMHO we
>should 
>concentrate on one branch for 2.2.0 and one for 2.3 development, and
>refrain 
>from big refactoring projects in 2.3 until 2.2.1 is out. Nobody will
>try out 
>all these different 2.2 branches, so these fixes won't get additional 
>testing. In the contrary, I believe that they would get more testing if
>they 
>were all in one 2.3 branch.  Also, I doubt that we can now plan ahead
>for 
>2.2.2, these plans are likely to become obsolete. We have a simple tool
>to 
>schedule bug fixes: Milestones in trac. If we put all bug fixes in the
>2.3 
>branch and set the bug milestones it is easy to get a list of all fixes
>that 
>need backporting.
>
>
>Georg

I also think these branches are overkill.

I would only use master and 2.2. No 2.3, it is so far away that it could be in 
master. 

2.2 should be always stable so that at any time a short living 2.2.x could be 
branched until the release is done. After the tag 2.2.x will be deleted then.

Similar to 
https://wiki.qt.io/Branch_Guidelines

Peter

Re: Bleeding-edge LyX

[Peter Kümmel]

Am 04.04.2016 um 12:24 schrieb Andrew Parsloe:

On 4/04/2016 10:19 a.m., Andrew Parsloe wrote:

On 4/04/2016 9:02 a.m., Scott Kostyshak wrote:

On Mon, Apr 04, 2016 at 07:50:58AM +1200, Andrew Parsloe wrote:

On 4/04/2016 5:38 a.m., Scott Kostyshak wrote:

On Sun, Apr 03, 2016 at 10:14:18AM +1200, Andrew Parsloe wrote:

On 3/04/2016 2:44 a.m., Peter Kümmel wrote:
I've downloaded a more recent version, and the console window is absent,
which is good. However, there is a problem with \lyxformat numbers. I see
that a new document in bleeding-edge LyX is format 507. Documents in beta2
are 506 and are not converted. Looking at the messages pane (newfile1.lyx is
a 506 document),

Opening document D:\Documents\newfile1.lyx...Error: Document format failure



C:/Users/Andrew/AppData/Local/Temp/lyx_tmpdir.ZzYoSAnf4440/Buffer_convertLyXFormatiA4440.lyx
is not a readable LyX document.

Are you able to open 2.1.x files?

Scott

I hadn't tried that, but I've just done so, and no, 2.1.x files result in
the same error. (I've reverted to beta2 now.)

I wonder if the problem is that your 2.2.0dev binary either cannot find
lyx2lyx or is using a different lyx2lyx. Note that lyx and lyx2lyx are
separate programs so the lyx program calls lyx2lyx (thus your PATH is
important). Are you using this bleeding-edge LyX thing locally or did
you install it?

Scott

Having unzipped the download, you are presented with two directories, one 
labelled bin and one Resources. As I understand it, you simply copy these on 
top of the installed LyX. It sounds somewhat hair-raising. My bumbling about 
(it took me a number of attempts to work out exactly what to do although the 
instructions seem clear enough in hindsight) may well have had side-effects, 
including corrupting PATH. At this point I'll simply wait for rc1.

Andrew

In fact I've had another go, and now the bleeding edge LyX can open documents from 
earlier versions of LyX. Help > About lists the date of the build as 3 April, QT 
Version 5.5.1. The citation dialogue which you were looking for a windows user's 
comments on (#10019, & which is why I undertook this exercise) looks good, as far 
as I can tell. The minimum height is a little less than in 2.1.4, the minimum width 
the same. It seems to stretch horizontally and vertically as I would expect.

However, there are still problems with bleeding edge LyX and as you surmised, Scott, they 
do seem to centre around the path. The format of my custom modules is not updated to 60. 
I had to do that manually and the LyX icon in the task bar, when LyX is being used, is 
the windows default icon for a program. When I try to change the icon windows responds: 
Windows can't find the file %Program Files%\LyX 2.2\bin\lyx.exe. When I browse to 
C:\Program Files (x86)\LyX 2.2\bin\lyx.exe it tells me that "the file C:\Program 
Files (x86)\LyX 2.2\bin\lyx.exe" contains no icons. Whether this is the fault of b-e 
LyX or me, I don't know.



The missing icon is a bug of b-e.


Andrew

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: Issues to discuss for 2.2.0rc1

[Peter Kümmel]

Am 2. April 2016 18:48:12 MESZ, schrieb Scott Kostyshak <skost...@lyx.org>:
>On Sat, Apr 02, 2016 at 11:11:33AM +0200, Peter Kümmel wrote:
>> 
>> I've found a solution for the strange crashes, strfwd.h must always
>included first, if not the compiler makes assumption which are wrong.
>> Now config.h for msvc2015 includes strfwd.h, not very nice but it
>solves the issue.
>
>Thank you for the fix.
>
>> So I think we could risk a msvc2015/Qt 5.6.0 release.
>
>I want to make sure I understand this statement. I interpret this to
>mean that it might not be crazy of us to do a MSVC2015/Qt 5.6.0
>release.
>
>Or should I interpret it to mean that you now recommend a
>MSVC2015/Qt 5.6.0 release over a MSVC2010/Qt 5.5.1 release?
>
>Scott

I recomment now the msvc2015/Qt5.6.0 build. I think the risk is minimal, sure 
we drop the beta feedback, but I have the impression there was not much 
feedback. And 5.6 has features which users will miss, especially on Win 10.

And when we get horror feedback from the rc1 we could still go back.

Btw, why are the betas and rcs not announced on the webpage?

Peter

Re: Bleeding-edge LyX

[Peter Kümmel]

Am 2. April 2016 11:26:06 MESZ, schrieb Andrew Parsloe :
>Hullo Peter,
>I've tried twice now to get a working bleeding-edge LyX (on a windows 7
>
>machine), since there have been occasions recently when it would have 
>been helpful to have someone testing latest commits on a windows 
>machine. Everything seems to function until I launch LyX. A console 
>window opens, and then LyX is launched, but as you can see from the 
>attachment, the console window displays three error messages, and 
>remains open. Closing the console window closes LyX. With these errors 
>present, I'm reluctant to do anything serious with the resulting LyX.
>
>Andrew
>
>
>---
>This email has been checked for viruses by Avast antivirus software.
>https://www.avast.com/antivirus

Lyx gives a lot of warnings. I don't think these are critical.

The console is enabled for bleeding edge build, maybe not a good idea. In a 
release the console is just disabled, so there is no differrence in the lyx 
functionality.
I will disable the console for bleeding edge, too.

Thanks for testing bleeding edge, I already was thinking about killing it.

Peter

Re: Issues to discuss for 2.2.0rc1

[Peter Kümmel]

Am 27.03.2016 um 21:38 schrieb Uwe Stöhr:

Am 20.03.2016 um 21:48 schrieb Scott Kostyshak:


Peter stated [1] that the patch is not necessary for compilation with
MSVC 2010.


But it doesn't harm then, see my today's post in the plans thread.


It seems the majority opinion is to release rc1 (and final
2.2.0) with Qt 5.5.1 compiled with MSVC 2010. Uwe, are you OK with that?


As I just wrote in the other thread I prefer Qt 5.6.
I can nevertheless release RC1 with Qt5.5.1/MSVC2010 and also a Qt 5.6 version. 
However, for the final release I won't maintain/offer support for a Qt 5.5.1 
build. Due to lack of time I will have to focus on one version and Qt 5.6 
offers a long term support, meaning I can assume that this version will be 
supported by the Qt people for the full life time of LyX 2.2.

I hope you can understand my decision.

regards Uwe



I've found a solution for the strange crashes, strfwd.h must always included 
first, if not the compiler makes assumption which are wrong.
Now config.h for msvc2015 includes strfwd.h, not very nice but it solves the 
issue.

So I think we could risk a msvc2015/Qt 5.6.0 release.

Peter

Re: Plan for 2.2.0rc1

[Peter Kümmel]

Am 27.03.2016 um 21:33 schrieb Uwe Stöhr:

Am 19.03.2016 um 08:18 schrieb Scott Kostyshak:


Uwe, are you OK with shipping the official RC1 with 5.5.1 and MSVC 2010?
 From what I understand, that's the recommendation of Georg and Peter and
it seems like the safest approach.


This is not fine with me. My spare time is limited and I need to minimize the 
time to support LyX. With Qt 5.6 I can rely on a long term support. I already 
benefited from this with Qt 4.8.

I have been busy the last days but meanwhile used LyX 2.2git intensively for 2 
documentation projects with success. I used the Qt 5.6/MSVC2015 build and it is 
is faster than the Qt 5.5.1/MSVC 2010 build. I did not experience any 
regressions between both builds.

So all I need is the patch from Peter in master and then I am ready for LyX 
2.2RC1. Please note that the patch does not destroy anything, I applied it for 
all builds and I cannot see a problem.


I've commited the change.



So once again, please release RC1. I don't see why we should wait any longer.

regards Uwe

Re: Plan for 2.2.0rc1

[Peter Kümmel]

Am 11.03.2016 um 04:49 schrieb Scott Kostyshak:

On Thu, Mar 10, 2016 at 12:50:25AM +0100, Uwe Stöhr wrote:

Am 09.03.2016 um 04:37 schrieb Scott Kostyshak:


8. What am I missing?


- I need for Qt 5.6 this patch from Peter to be applied:
https://github.com/syntheticpp/lyx/commit/2470fb442cb2b04a69b2030f28f1da60221556a7?diff=unified


Peter, do you proppose this for 2.2.0?


No, not necessary for builds with msvc10.

And I only propose a 2.2.0 release with Qt 5.5.1 and msvc10. We could not 
change compilers and Qt versions like socks.




- bug http://www.lyx.org/trac/ticket/10009


I'm glad you figured out a workaround for that.


- we still haven't done anything to fix the 2 layouts that will produce
uncompilable files (acmsiggraph and agutex). Please make a decision and I
will apply it that way.. It would be embarassing when we include outdated
layouts despite that we are aware of this.


OK I will take a look at this.


Uwe and Stephan, which Qt versions will you be able to release RC1 with?


In my opinion the RC should feature Qt 5.6. For Qt 5.6 I need MSVC 2015
Update 2 (no other MSVC version could be used). Qt 5.6 will be released next
week and I assume MSVC 2015 Update 2 too (there is already an RC out). If
http://www.lyx.org/trac/ticket/10009 cannot be solved I will have to try out
MinGW but there are reports that MinGW misses some things necessary for
Windows 10.


Will you be able to also release an installer using Qt 5.5.1 and Qt
4.8.6? This would be nice so that if we get a bug report that we can't
reproduce, we can ask them to try the 5.5.1 installer and that way we
can see whether the bug is due to LyX or to Qt.

Scott

Re: Qt5.6 and MSVC

[Peter Kümmel]

Am 04.03.2016 um 01:34 schrieb Uwe Stöhr:

I played a bit with Qt5.6RC and the latest MSVC 2015. I can compile current 
master without errors but finally I still get this linking error:

D:\LyXGit\Master\compile-2015\src\tests\check_ExternalTransforms.vcxproj" 
(standard target) (18) ->
   support.lib(os.obj) : error LNK2019: unresolved external symbol ___wgetmainargs 
referenced in function "void __cdecl lyx::support::os::init(int,char * * 
const)" (?init@os@support@lyx@@YAXHQAPAD@Z) 
[D:\LyXGit\Master\compile-2015\src\tests\check_ExternalTransforms.vcxproj]

D:\LyXGit\Master\compile-2015\bin\Release\check_ExternalTransforms.exe : fatal 
error LNK1120: 1 unresolved externals 
[D:\LyXGit\Master\compile-2015\src\tests\check_ExternalTransforms.vcxproj]

for the

- LyX.exe
- check_Length.exe
- check_ExternalTransforms.exe
- check_ListingsCaption.exe
- check_convert.exe

I still cannot imagine that there is a bug in MSVC because I get the same with 
MSVC 2013 and cannot imagine that users did not yet reported such a linking 
error.

Of course I can switch to MinGW but to me its seems we have a real issue that 
should be corrected.
I read that MinGW 4.9 is not fully capable of the windows handling in Win 10 so 
if possible I would prefer using MSVC for maintainability reasons. Of course if 
the mentioned error is not fixable I won't have another option.

thanks and regards
Uwe



___wgetmainargs was removed in 2015.

Please try this patch

https://github.com/syntheticpp/lyx/commit/2470fb442cb2b04a69b2030f28f1da60221556a7?diff=unified

Peter

Re: CMake issue

[Peter Kümmel]

Am 04.03.2016 um 03:58 schrieb Uwe Stöhr:

I have this code in my debug build script:

cmake %LYX_SOURCE% -GNinja -G"Visual Studio 14" -DLYX_ENABLE_CXX11=ON 
-DLYX_USE_QT=QT5 -DLYX_ENABLE_EXPORT_TESTS=0 -DLYX_MERGE_FILES=0 -DLYX_NLS=1 
-DLYX_INSTALL=0 -DLYX_RELEASE=0 -DLYX_CONSOLE=FORCE -DLYX_3RDPARTY_BUILD=1
msbuild lyx.sln /p:Configuration=Debug /t:LyX /t:tex2lyx

and get the error that a target "LyX" does not exist in the lyx.sln file. That is true, 
there is only a project folder named "LyX". From within MSVC I can compile this folder 
but not from outside because the target is missing.

I get the same problem with MSVC2010. In LyX's 2.1.x branch the target is 
there, but not in master.

thanks and regards
Uwe



You've passed -G two times.

Peter

Re: beta2?

[Peter Kümmel]

Am 21.02.2016 um 17:59 schrieb Scott Kostyshak:

On Mon, Feb 15, 2016 at 05:06:19PM +0100, Kornel Benko wrote:

Am Sonntag, 14. Februar 2016 um 23:39:00, schrieb Pavel Sanda <sa...@lyx.org>

Peter Kümmel wrote:

Uwe still gets the following errors from the tar I sent to him:

D:\LyXGit\LyX22beta3\3rdparty\boost\boost/numeric/conversion/detail/numeric_cast_traits.hpp(12):
fatal error C1083: File (Include) cannot be opened:
"boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_common.hpp":
No such file or directory
[D:\LyXGit\LyX22beta3\compile-2010\src\support\support.vcxproj]


I only tested with "build5-2010-installer.bat"


Is this script now used to build official installer?
In case of yes, would be our cmake gurus able to add routine
which spits out md5sum of installer binaries which could Uwe
posts in his email when publishing the binaries?

Pavel


For me it is not clear, how the binary zip-file is created on windows.
If I would know, I could create a new target to compute md5sum for this 
zip-file.
I created and committed a cmake-script to be used for this task.


It would be really nice to get this working. Peter, do you have an idea
of how to accomplish this?


AFAIK the installer is build in two steps,
1. build LyX and install locally
2. point the install file creater (NSIS) to the local LyX installation and 
start NSIS manually

So I don't know were we can calculate any sensible md5sum with cmake.

Peter


Note that this just came up on the news today:
http://blog.linuxmint.com/?p=2994

Scott

Re: [LyX/master] Add missing boost files to source package

[Peter Kümmel]

Am 16.02.2016 um 20:08 schrieb Georg Baum:

Peter Kümmel wrote:


Am 15.02.2016 um 22:06 schrieb Georg Baum:




Done .


Thanks.


What about the unused files libs/regex/regex.vcproj,
libs/signals/signals.vcproj, libs/regex/src/icu.cpp,
libs/regex/src/usinstances.cpp and libs/regex/src/wc_regex_traits.cpp?
I'd like to remove them from git.


I would not fiddle around with files distributed by boost.
Just use all the files created by bcp/extract.sh.


Then we need to add them to the make rules. Currently they are not built,
and having them in git, but not in the source packages, and not in the build
does not make sense.


When you remove then, don't forget to update .gitignore or the extract script.




Georg

Re: [LyX/master] Add missing boost files to source package

[Peter Kümmel]

Am 15.02.2016 um 22:06 schrieb Georg Baum:

Peter Kümmel wrote:


commit 6de524e6cf2d13636b04b9bb850d0a8b1eaa398b
Author: Peter Kümmel <kuem...@lyx.org>
Date:   Sat Feb 13 18:34:08 2016 +0100

 Add missing boost files to source package

 and remove Visual Studio files, we build with CMake on Windows.

diff --git a/3rdparty/boost/Makefile.am b/3rdparty/boost/Makefile.am
index cfac86b..fcb9ff7 100644
--- a/3rdparty/boost/Makefile.am
+++ b/3rdparty/boost/Makefile.am
@@ -4,13 +4,14 @@ noinst_LIBRARIES = liblyxboost.a

  EXTRA_DIST = boost \
  CMakeLists.txt \
+   LICENSE_1_0.txt \
  libs/CMakeLists.txt \
  libs/regex/CMakeLists.txt \
-   libs/regex/regex.vcproj \
  libs/regex/src/CMakeLists.txt \
  libs/signals/CMakeLists.txt \
-   libs/signals/signals.vcproj \
-   libs/signals/src/CMakeLists.txt
+   libs/signals/src/CMakeLists.txt \
+


boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_common.hpp

\
+


boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp



Done .


These two additions are not needed, right? At least the files appear in the
tar also before this changes.

What about the unused files libs/regex/regex.vcproj,
libs/signals/signals.vcproj, libs/regex/src/icu.cpp,
libs/regex/src/usinstances.cpp and libs/regex/src/wc_regex_traits.cpp? I'd
like to remove them from git.


I would not fiddle around with files distributed by boost.
Just use all the files created by bcp/extract.sh.

Peter




Georg

Re: State of master and release process

[Peter Kümmel]

Am 15.02.2016 um 22:33 schrieb Scott Kostyshak:

Just an update for those who have not been following the other
conversations, and also a question:

beta2 has been tagged, and the tars have been posted. We have not
formally released it because we are still trying to make it so that it
is possible to compile on Windows from the self-contained archive. There
is a problem with extracting the tar on Windows, so I have just sent Uwe
a zip file containing the same files that the tar contains.

If the zip file extracts correctly and Uwe can compile for Windows, does
this mean that we should release beta2 as long as we post the zip file
and in the email announcement we recommend the zip file if compiling on
Windows? Or because the tar has issues with being extracted on Windows,
we must move to beta3 which hopefully (still not confirmed) would
produce a tar that can be extracted correctly with the Windows build? A
separate question is does it matter that the 'make lyxdist' command for
beta2 did not produce the zip file that would be posted as beta2?

It seems to me that although it is indicative of an inexperienced
release manager, the best thing would be to move to beta3, and confirm
with Uwe before posting the files that the archive can be extracted and
that the Windows build succeeds. I don't have a strong opinion on this
though.

On a separate note, master branch is open. Depending on the above
discussion we might move very soon to beta3, so please nothing
non-trivial.

Scott



I would say: release tag 2.2.0beta2.
There is only the problem with untaring on Windows

For beta3:

- add zip to lyxdist
- some cleanup in boost

Peter

Re: [LyX/master] Add missing boost files to source package

[Peter Kümmel]

Am 15.02.2016 um 22:06 schrieb Georg Baum:

Peter Kümmel wrote:


commit 6de524e6cf2d13636b04b9bb850d0a8b1eaa398b
Author: Peter Kümmel <kuem...@lyx.org>
Date:   Sat Feb 13 18:34:08 2016 +0100

 Add missing boost files to source package

 and remove Visual Studio files, we build with CMake on Windows.

diff --git a/3rdparty/boost/Makefile.am b/3rdparty/boost/Makefile.am
index cfac86b..fcb9ff7 100644
--- a/3rdparty/boost/Makefile.am
+++ b/3rdparty/boost/Makefile.am
@@ -4,13 +4,14 @@ noinst_LIBRARIES = liblyxboost.a

  EXTRA_DIST = boost \
  CMakeLists.txt \
+   LICENSE_1_0.txt \
  libs/CMakeLists.txt \
  libs/regex/CMakeLists.txt \
-   libs/regex/regex.vcproj \
  libs/regex/src/CMakeLists.txt \
  libs/signals/CMakeLists.txt \
-   libs/signals/signals.vcproj \
-   libs/signals/src/CMakeLists.txt
+   libs/signals/src/CMakeLists.txt \
+


boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_common.hpp

\
+


boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp

These two additions are not needed, right? At least the files appear in the
tar also before this changes.


Yes, only the .txt files are needed.



What about the unused files libs/regex/regex.vcproj,
libs/signals/signals.vcproj, libs/regex/src/icu.cpp,
libs/regex/src/usinstances.cpp and libs/regex/src/wc_regex_traits.cpp? I'd
like to remove them from git.



I'm sure only about .vcproj.



Georg

Re: beta2?

[Peter Kümmel]

Am 14.02.2016 um 21:27 schrieb Jean-Marc Lasgouttes:

Le 14/02/16 19:54, Georg Baum a écrit :

Peter Kümmel wrote:


Am 14.02.2016 um 19:03 schrieb Scott Kostyshak:


Why is numeric_cast_traits_common.hpp not being found?


Have you checked if it's part of the tar you send to Uwe?


The files I listed above are part of the tar. I will send the tar to you
privately.


That explains why they did not show up in my comparison of the beta1 tar and
the git tree. I did not really understand why I could have missed them.


Probably related to this commit:

commit 5287f1c8b6a9e719492cf7350c304efb978c664c
Author: Peter Kümmel <kuem...@lyx.org>
Date:   Sun Dec 20 13:32:33 2015 +0100

 default tar-v7 format supports only 99 character pathes


We use tar-pax now, and it might not be handled very well by some old 
utilities. From what is said here

https://www.gnu.org/software/automake/manual/html_node/List-of-Automake-options.html
I believe that "ustar" would have been a better alternative.


Thanks for this hint!
I've tested it with ustar and it is indeed the better choice.

I've committed the change to ustar.

Peter



JMarc

Re: beta2?

[Peter Kümmel]

Am 14.02.2016 um 19:03 schrieb Scott Kostyshak:

On Sun, Feb 14, 2016 at 06:36:15PM +0100, Peter Kümmel wrote:



Am 14.02.2016 um 17:17 schrieb Scott Kostyshak:

On Sat, Feb 13, 2016 at 01:44:30PM -0500, Scott Kostyshak wrote:

On Sat, Feb 13, 2016 at 01:24:20PM -0500, Scott Kostyshak wrote:

On Sat, Feb 13, 2016 at 07:11:48PM +0100, Uwe Stöhr wrote:

Am 13.02.2016 um 18:01 schrieb Scott Kostyshak:


Thanks for testing, Peter. I'll wait for a fix, and then I suppose we
move to beta3?


Sorry, but why do we act like beginners?

I wrote what is missing in the tarball. So why not add these files, send me
the tarball by private mail to check and then announce a new beta


You are right that this is what I should have done for beta2. I will do
this now before releasing beta3. I'll build the tar and send it to you
privately. After you confirm that you can compile the Windows build from
only the tar, I will post the tar and push the git tag and git commits.


I've sent the tars to you privately. Can you do a fresh build from them?


Uwe still gets the following errors from the tar I sent to him:

D:\LyXGit\LyX22beta3\3rdparty\boost\boost/numeric/conversion/detail/numeric_cast_traits.hpp(12):
fatal error C1083: File (Include) cannot be opened:
"boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_common.hpp":
No such file or directory
[D:\LyXGit\LyX22beta3\compile-2010\src\support\support.vcxproj]


I only tested with "build5-2010-installer.bat"



I was hoping that 6de524e6 fixed these. Is there still something we
need to do? Looking in the tar, I see

./3rdparty/boost/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp
./3rdparty/boost/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_common.hpp
./3rdparty/boost/boost/numeric/conversion/detail/numeric_cast_traits.hpp
./3rdparty/boost/boost/numeric/conversion/numeric_cast_traits.hpp

Why is numeric_cast_traits_common.hpp not being found?


Have you checked if it's part of the tar you send to Uwe?


The files I listed above are part of the tar. I will send the tar to you
privately.

Scott

Re: beta2?

[Peter Kümmel]

Am 14.02.2016 um 19:03 schrieb Scott Kostyshak:


Why is numeric_cast_traits_common.hpp not being found?


Have you checked if it's part of the tar you send to Uwe?


The files I listed above are part of the tar. I will send the tar to you
privately.


When I unpack with WinRAR it looks like this

$ ls -l 3rdparty/boost/boost/numeric/conversion/detail/preprocessed/
total 56
-rw-r--r-- 1 numeric_cast_traits_commo
-rw-r--r-- 1 numeric_cast_traits_long_

and when I run "tar vxf lyx-2.2.0beta3.tar.gz" from the git console it is ok.

So the unzip tool has a problem, maybe because of the long path length.

Maybe we should also distribute a zip file.



Scott

Re: beta2?

[Peter Kümmel]

Am 14.02.2016 um 17:17 schrieb Scott Kostyshak:

On Sat, Feb 13, 2016 at 01:44:30PM -0500, Scott Kostyshak wrote:

On Sat, Feb 13, 2016 at 01:24:20PM -0500, Scott Kostyshak wrote:

On Sat, Feb 13, 2016 at 07:11:48PM +0100, Uwe Stöhr wrote:

Am 13.02.2016 um 18:01 schrieb Scott Kostyshak:


Thanks for testing, Peter. I'll wait for a fix, and then I suppose we
move to beta3?


Sorry, but why do we act like beginners?

I wrote what is missing in the tarball. So why not add these files, send me
the tarball by private mail to check and then announce a new beta


You are right that this is what I should have done for beta2. I will do
this now before releasing beta3. I'll build the tar and send it to you
privately. After you confirm that you can compile the Windows build from
only the tar, I will post the tar and push the git tag and git commits.


I've sent the tars to you privately. Can you do a fresh build from them?


Uwe still gets the following errors from the tar I sent to him:

D:\LyXGit\LyX22beta3\3rdparty\boost\boost/numeric/conversion/detail/numeric_cast_traits.hpp(12):
fatal error C1083: File (Include) cannot be opened:
"boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_common.hpp":
No such file or directory
[D:\LyXGit\LyX22beta3\compile-2010\src\support\support.vcxproj]

I was hoping that 6de524e6 fixed these. Is there still something we
need to do? Looking in the tar, I see

./3rdparty/boost/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp
./3rdparty/boost/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_common.hpp
./3rdparty/boost/boost/numeric/conversion/detail/numeric_cast_traits.hpp
./3rdparty/boost/boost/numeric/conversion/numeric_cast_traits.hpp

Why is numeric_cast_traits_common.hpp not being found?


Have you checked if it's part of the tar you send to Uwe?

Here make lyxdist adds it to the tar.




Scott

Re: beta2?

[Peter Kümmel]

Am 13.02.2016 um 10:57 schrieb Georg Baum:

Scott Kostyshak wrote:


I agree that it would be nice to remove unnecessary files. As far as
figuring out which files are unnecessary, I volunteer to take any
experimental patch, build a tar ball, and send it to Uwe to see if he
has time to build the test tar ball so we can see if he gets an error.


The files are already missing from the beta2 tarball (because they are not
listed in Makefile.am). If Uwe can build from it, we can remove them from
git.


No, beta2 does not build on Windows because of missing

3rdparty/boost/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_common.hpp
3rdparty/boost/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp

Peter




Georg

Re: beta2?

[Peter Kümmel]

Am 13.02.2016 um 18:01 schrieb Scott Kostyshak:

On Sat, Feb 13, 2016 at 12:34:26PM +0100, Peter Kümmel wrote:

Am 13.02.2016 um 10:57 schrieb Georg Baum:

Scott Kostyshak wrote:


I agree that it would be nice to remove unnecessary files. As far as
figuring out which files are unnecessary, I volunteer to take any
experimental patch, build a tar ball, and send it to Uwe to see if he
has time to build the test tar ball so we can see if he gets an error.


The files are already missing from the beta2 tarball (because they are not
listed in Makefile.am). If Uwe can build from it, we can remove them from
git.


No, beta2 does not build on Windows because of missing

3rdparty/boost/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_common.hpp
3rdparty/boost/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp

Peter


Thanks for testing, Peter. I'll wait for a fix, and then I suppose we
move to beta3?


OK, files now are part of the tar.



Scott

Finding Qt on Windows with CMake GUI

[Peter Kümmel]

Just for the record:

When configuring LyX on Windows with cmake-gui,
CMAKE_PREFIX_PATH  must point to a Qt installation like
"C:/Qt/Qt5.5.1/5.5/msvc2010".

Peter

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

[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: Beta hopefully soon, only waiting on Windows installer(s)

[Peter Kümmel]

Am 18. Januar 2016 09:33:17 MEZ, schrieb "Uwe Stöhr" <uwesto...@web.de>:
>
>
>  Original Message  
>From: Peter Kümmel
>Sent: Montag, 18. Januar 2016 03:49
>To: Uwe Stöhr; Scott Kostyshak; LyX Developers
>Subject: Re: Beta hopefully soon, only waiting on Windows installer(s)
>
>Am 18. Januar 2016 01:24:38 MEZ, schrieb "Uwe Stöhr"
><uwesto...@web.de>:
>>Am 17.01.2016 um 03:22 schrieb Peter Kümmel:
>>
>>> I would release the beta with the available Windows installer, but
>>would also mention, that because of men power this time on Windows
>>there will be nothing better that beta quality.
>>> In the announcement you could mention that we are busy improving
>>this, but that at the moment no Windows developer has the time to
>>create a reliable installer and that we are very interested in someone
>>who wanna help out.
>>
>>But what is going on here? I reported that i am ready for beta1. I
>even
>>
>>presented you an installer.
>>And to repeat myself, building the installer was never a problem, 
>>building LyX with Qt 5 was the problem.
>>
>
>But there must be no problem in building with Qt5. And if you report
>problems about cmake could not find Qt5 something is fishy on your
>system.
>
>Damn no, I did not report this. I can compile Lyx with Qt 5.5.1 with
>MSVC 2010, but not with MSVC 2012 Or newer.
>
>CMake could and can find Qt, I only need to specify some Qt paths. I
>think that specifying only one should be sufficient too.‎
>
>That your script doesn't work is another issue. As I wrote I could
>compile with the script before you changed it.
>
> > And nobody had an idea what you are doing when creating the
>installer.
>
>I wrote you an email with the instructions. Have you read it? Have you
>tried it out? I'm upset to hear such statements if people did not even
>tried it. I asked you for feedback and got no reply.

You mean the installer instructions? Yes I tried yesterday and it worked. I 
also saw your nsh changes in git. I further plan to investigate how a mingw 
build could be integrated. Also I wonder what for files from the zip packages 
are really needed and if there would be a better place than a downloadable zip 
file for them.



>
>> >Sorry, but it is an effrontery to say that no dev has the time nor
>the 
>>ability to build a reliable installer!
>
>> But it looked like you are not able to get a straightforward build, 
>
>Please read what I wrote. I did not write thus! I wrote the opposite
>and requested you to test a ready installer.
>
>> you told you have to touch 40 pathes to get a build up. Hearing this,
>the only reaction is "wtf is he doing". 
>
>Just run CMake and set Qt to Qt4. For Qt 5 there are only 6 Qt paths.
>
>>> Of course the installer for beta works fine - tested for 2 days on 5
>
>>PCs. And no, LyX on Windows is as stable as LyX on Mac and Unix.
>
>> This was to early, because until now we have no beta release. You
>have to build the installer after the beta is out.
>
>Damn, the INSTALLER. Of course I will build LYx wheb it is released.
>
>Uwe

Re: compilation problems with Qt 5.5.1 and MSVC 2010

[Peter Kümmel]

Am 18. Januar 2016 09:17:01 MEZ, schrieb "Uwe Stöhr" <uwesto...@web.de>:
>
>
>From: Peter Kümmel
>
>Sent: Montag, 18. Januar 2016 03:18‎
>
>
>> Something is different on your system, there should be no problem
>with finding Qt 5. How actual is your cmake installation? 
>
>
>Up to date (3.4.1). Qt is in the folder you hardcoded in the script.
>
>
>> Or do you use a years old Windows for the build?
>
> What do you imply with this sentence?‎ I'm on Win7 64bit.
>
>> Latest build folder name should be build5-msvc2010, didn't land this
>commit upstream? 
>
>
>It is. This folder.
>
>
>However, with the build script I uploaded to git I can and could
>compile LyX so we don't need to invest time in your script to release a
>beta version.
>

Forget it, your script or system is broken. 

>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" <uwesto...@web.de>:
>
>
>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: [patch] - GIT - version control for LyX documents not detected

[Peter Kümmel]

Am 18. Januar 2016 23:25:03 MEZ, schrieb Pavel Sanda :
>Stephan Witt wrote:
>> The attached patch fixes the broken detection of GIT version control.
>> It seems so that Qt is caching the file meta data and fools the test
>> of file emptiness. Perhaps this has changed with Qt5 and didn???t
>happen
>> with Qt4???
>
>Bad news, if your analysis is correct, we might encounter the same
>problem
>in other parts of the code as well. I don't have easy access to qt5 to
>test.
>
>Quick check says we use is FileEmpty also in:
>Buffer.cpp:   enable = (d->preview_file_).exists() &&
>!(d->preview_file_).isFileEmpty();
>LaTeX.cpp:rerun = idxfile.exists() && idxfile.isFileEmpty();
>LaTeX.cpp:if (head.haschanged(nlofile) || (nlofile.exists() &&
>nlofile.isFileEmpty()))
>
>Pavel

I did not follow this git stuff, but I assume current implementation tries to 
use system git calls via Qt classes, am I right? I really could imagine this 
makes problems, because of Qt. 

Afaik QtCreator tries the same, is any code used from there in LyX?

Had someone the idea to use libgit2 instead of the system git? Was it 
evaluated? I assume then there we have much more control over the git files.

Peter 

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: compilation problems with Qt 5.5.1 and MSVC 2010

[Peter Kümmel]

Hello Uwe,

as you told, you have big problems in settings up clean build.
Therefore I've changed the build5-2010.bat file you added for building 
with MSVC2010.


This script now works with a double click, and builds LyX with MSVC2010 
in a clean build directory.


Three pathes are hardcoded:
- Qt installation qt C:\Qt
- MSVC2010 installation in C:\Program Files (x86)\Microsoft Visual 
Studio 10.0\VC
- and the deps at the same level as the LyX sources 
lyx20-deps-msvc2010-x86\deps20 (I disabled the automatic download)


I assume the pathes are the same on most systems.
You only have to unpack the deps-msvc2010-x86 folder once at the right 
place.


A simple double click creates the folder "build5-msvc2010" with
the LYX_INSTALLED files. Please use these files for you installer.

We should change this script until it also works for you.
The goal is that you don't have to touch it before you execute it.

I really hope this improves the current installer chaos.

Peter

Re: Beta hopefully soon, only waiting on Windows installer(s)

[Peter Kümmel]

Am 17.01.2016 um 08:06 schrieb Scott Kostyshak:



I would release the beta with the available Windows installer, but would also 
mention, that because of men power this time on Windows there will be nothing 
better that beta quality.
In the announcement you could mention that we are busy improving this, but that 
at the moment no Windows developer has the time to create a reliable installer 
and that we are very interested in someone who wanna help out.
It would be a starter project which could be done without C++ knowledge.


Good idea. We can indeed put a note in the announcement of the beta
release.


Initially I didn't like the idea to do a 5.5.1 msvc2010 release but it 
seems we have to go this way ATM.


I fixed the build script for msvc2010 and when Uwe could build the 
installer after the final release commits, I think we could drop the

warning about the installer. It would be as stable as before.



Scott

Re: compilation problems with Qt 5.5.1 and MSVC 2010

[Peter Kümmel]

Am 18. Januar 2016 01:10:41 MEZ, schrieb "Uwe Stöhr" <uwesto...@web.de>:
>Am 17.01.2016 um 18:59 schrieb Peter Kümmel:
>
> > as you told, you have big problems in settings up clean build.
>> Therefore I've changed the build5-2010.bat file you added for
>building
>> with MSVC2010.
>
>As I reported proudly I was able to get a clean build. I still have
>some 
>troubles with CMake and reported them as
>http://www.lyx.org/trac/ticket/9927
>
>The script you modified is the one I uploaded after I could use it to 
>compile LyX with it with just a click.
>
>Now I cannot use the script to build LyX: double-clicking on it gives 
>starts a console that is clased after a few seconds.  The error message
>is:
>
>---
>CMake Error at CMakeLists.txt:561 (find_package):
>   By not providing "FindQt5Core.cmake" in CMAKE_MODULE_PATH this 
>project has
>   asked CMake to find a package configuration file provided by 
>"Qt5Core", but
>   CMake did not find one.
>
>   Could not find a package configuration file provided by "Qt5Core" 
>with any
>   of the following names:
>
> Qt5CoreConfig.cmake
> qt5core-config.cmake
>
>   Add the installation prefix of "Qt5Core" to CMAKE_PREFIX_PATH or set
>   "Qt5Core_DIR" to a directory containing one of the above files.  If
>"Qt5Core" provides a separate development package or SDK, be sure it
>has
>   been installed.
>
>-- Configuring incomplete, errors occurred!
>See also "D:/LyXGit/compile-msvc2010/CMakeFiles/CMakeOutput.log".
>---
>
>I miss in your script a method to select to build a devel or an install
>
>build.
>Moreover
>-DLYX_MERGE_REBUILD=1 -DLYX_MERGE_FILES=1
>never worked for me. i get then compilation errors. Thus I am forced to
>use
>-DLYX_MERGE_REBUILD=0 -DLYX_MERGE_FILES=0
>
>> I really hope this improves the current installer chaos.
>
>I am very thankful that you help me here but I don't understand what
>you 
>mean with "installer chaos". I provided a buggy installer for alpha2 
>because I could not test it. That was it. My main problems are to build
>
>LyX because of the CMake bugs and because I first need to find out that
>
>LyX cannot be built with MSVC 2012 or newer.
>
>regards Uwe

Something is different on your system, there should be no problem with finding 
Qt 5. How actual is your cmake installation? Or do you use a years old Windows 
for the build?

Latest build folder name should be build5-msvc2010, didn't land this commit 
upstream? 

Script maybe misses the correcr man dir pass this could be fixed.

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: compilation problems with Qt 5.5.1 and MSVC 2010

[Peter Kümmel]

>
>I miss in your script a method to select to build a devel or an install

We need a reliable script for the installer input, which only builds lyx 
nothing else, this is the intention. No parameters no choice. 

>Moreover
>-DLYX_MERGE_REBUILD=1 

This flag is only needed when you rebuild again, which is the case here, each 
time the build dir is clean.

-DLYX_MERGE_FILES=1
>never worked for me. i get then compilation errors. Thus I am forced to
>use
>-DLYX_MERGE_REBUILD=0 -DLYX_MERGE_FILES=0
>
>> I really hope this improves the current installer chaos.
>
>I am very thankful that you help me here but I don't understand what
>you 
>mean with "installer chaos". I provided a buggy installer for alpha2 
>because I could not test it. That was it. My main problems are to build
>
>LyX because of the CMake bugs and because I first need to find out that
>
>LyX cannot be built with MSVC 2012 or newer.
>
>regards Uwe

Re: Beta hopefully soon, only waiting on Windows installer(s)

[Peter Kümmel]

Am 18. Januar 2016 01:24:38 MEZ, schrieb "Uwe Stöhr" <uwesto...@web.de>:
>Am 17.01.2016 um 03:22 schrieb Peter Kümmel:
>
>> I would release the beta with the available Windows installer, but
>would also mention, that because of men power this time on Windows
>there will be nothing better that beta quality.
>> In the announcement you could mention that we are busy improving
>this, but that at the moment no Windows developer has the time to
>create a reliable installer and that we are very interested in someone
>who wanna help out.
>
>But what is going on here? I reported that i am ready for beta1. I even
>
>presented you an installer.
>And to repeat myself, building the installer was never a problem, 
>building LyX with Qt 5 was the problem.
>

But there must be no problem in building with Qt5. And if you report problems 
about cmake could not find Qt5 something is fishy on your system. And nobody 
had an idea what you are doing when creating the installer.


>Sorry, but it is an effrontery to say that no dev has the time nor the 
>ability to build a reliable installer!

But it looked like you are not able to get a straightforward build, you told 
you have to touch 40 pathes to get a build up. Hearing this, the only reaction 
is "wtf is he doing". 

>
>Of course the installer for beta works fine - tested for 2 days on 5 
>PCs. And no, LyX on Windows is as stable as LyX on Mac and Unix.

This was to early, because until now we have no beta release. You have to build 
the installer after the beta is out.

Re: compilation problems with Qt 5.5.1 and MSVC 2010

[Peter Kümmel]

Am 18. Januar 2016 01:10:41 MEZ, schrieb "Uwe Stöhr" <uwesto...@web.de>:
>Am 17.01.2016 um 18:59 schrieb Peter Kümmel:
>
> > as you told, you have big problems in settings up clean build.
>> Therefore I've changed the build5-2010.bat file you added for
>building
>> with MSVC2010.
>
>As I reported proudly I was able to get a clean build. I still have
>some 
>troubles with CMake and reported them as
>http://www.lyx.org/trac/ticket/9927
>
>The script you modified is the one I uploaded after I could use it to 
>compile LyX with it with just a click.
>
>Now I cannot use the script to build LyX: double-clicking on it gives 
>starts a console that is clased after a few seconds.  The error message
>is:
>
>---
>CMake Error at CMakeLists.txt:561 (find_package):
>   By not providing "FindQt5Core.cmake" in CMAKE_MODULE_PATH this 
>project has
>   asked CMake to find a package configuration file provided by 
>"Qt5Core", but
>   CMake did not find one.
>
>   Could not find a package configuration file provided by "Qt5Core" 
>with any
>   of the following names:
>
> Qt5CoreConfig.cmake
> qt5core-config.cmake
>
>   Add the installation prefix of "Qt5Core" to CMAKE_PREFIX_PATH or set
>   "Qt5Core_DIR" to a directory containing one of the above files.  If
>"Qt5Core" provides a separate development package or SDK, be sure it
>has
>   been installed.
>
>-- Configuring incomplete, errors occurred!
>See also "D:/LyXGit/compile-msvc2010/CMakeFiles/CMakeOutput.log".
>---
>
>I miss in your script a method to select to build a devel or an install
>
>build.
>Moreover
>-DLYX_MERGE_REBUILD=1 -DLYX_MERGE_FILES=1
>never worked for me. i get then compilation errors. Thus I am forced to
>use
>-DLYX_MERGE_REBUILD=0 -DLYX_MERGE_FILES=0
>
>> I really hope this improves the current installer chaos.
>
>I am very thankful that you help me here but I don't understand what
>you 
>mean with "installer chaos". I provided a buggy installer for alpha2 
>because I could not test it. That was it. My main problems are to build
>
>LyX because of the CMake bugs and because I first need to find out that
>
>LyX cannot be built with MSVC 2012 or newer.
>
>regards Uwe

Is Qt installed on D: in your system? This could be the reason that Qt is not 
found. Please check the Qt path bin the script.

Is it a problem on your system to use Qt's default paths? Maybe you should also 
use a virtual machine only used for building lyx.

Re: Windows: release with Qt 5.5.1 or 5.6?

[Peter Kümmel]

Am 18. Januar 2016 01:32:15 MEZ, schrieb "Uwe Stöhr" :
>Am 16.01.2016 um 16:58 schrieb Scott Kostyshak:
>
>> Uwe, I know you do not have much time but are you willing to make
>both
>> installers? It seems there is help available for both the MSVC and
>mingw
>> if you get stuck.
>
>To repeat, the installer is completely independent of the compiler! So 
>if you fear bugs in the installer, it is there, no matter how LyX was
>built.
>
>As I wrote, I have a very well tested installer ready and won't invest 
>another week to dive into the compiler business. it is also not 
>necessary to release a beta. LyX 2.2 is very stable in my experience
>and 
>it is sufficient that users use it and give us feedback.
>
>Please push beta1 right now.

Do you plan to rebuild the installer after the official beta commit? Nobody 
knows which changed are not in the already uploaded installer because since 
then there were commits.

>
>regards Uwe

Re: Beta hopefully soon, only waiting on Windows installer(s)

[Peter Kümmel]

>And to repeat myself, building the installer was never a problem, 

Great! And it looks like necessary stuff is committet by you to the repository.
Ideally all files needed for the installer would be part of the repository, but 
this would mean to add multiple MB of Windows binaries which is not an option.

Maybe we could think about a git submodle which could be checked out optionally.


>building LyX with Qt 5 was the problem.
>
>Sorry, but it is an effrontery to say that no dev has the time nor the 
>ability to build a reliable installer!
>
>Of course the installer for beta works fine - tested for 2 days on 5 
>PCs. And no, LyX on Windows is as stable as LyX on Mac and Unix.

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 <syntheti...@gmx.net>:



Am 15.01.2016 um 15:01 schrieb Stephan Witt:

Am 15.01.2016 um 14:41 schrieb Peter Kümmel <syntheti...@gmx.net>:


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: Beta hopefully soon, only waiting on Windows installer(s)

[Peter Kümmel]

Am 16. Januar 2016 23:43:12 MEZ, schrieb Scott Kostyshak :
>Dear all,
>
>Hopefully we will release beta1 very soon. As far as I'm concerned, the
>only thing we are waiting for is the Windows installer(s). The reason
>why we are waiting for this and not just proceeding with the other
>parts
>of the beta1 release is that there might be changes needed to the
>source
>to clear up the build issues. These changes should be included in
>beta1.
>There are some questions about the build process that we hope to clear
>up; and if Uwe is OK with it, I think it would be great to build both
>an
>MSVC installer and an MinGW installer. We all understand that Uwe does
>not have much time, but it also seems that it might not require too
>much
>of his time, thanks to the help from Georg, Peter, and Kornel for build
>and CMake issues.
>
>After that is cleared up, I will do some final commits and build the
>tar
>balls. It would be nice to have a day or so where there are no commits
>so that we are all encouraged to test beta1 for a day.
>
>Please let me know if I'm missing anything.
>
>Scott

I would release the beta with the available Windows installer, but would also 
mention, that because of men power this time on Windows there will be nothing 
better that beta quality. 
In the announcement you could mention that we are busy improving this, but that 
at the moment no Windows developer has the time to create a reliable installer 
and that we are very interested in someone who wanna help out. 
It would be a starter project which could be done without C++ knowledge.

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

[Peter Kümmel]

Am 15.01.2016 um 15:01 schrieb Stephan Witt:

Am 15.01.2016 um 14:41 schrieb Peter Kümmel <syntheti...@gmx.net>:


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

[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: MinGW: development/cmake/mingw.bat

[Peter Kümmel]

Am 12.01.2016 um 20:21 schrieb Peter Kümmel:

Hi Uwe, could you try development/cmake/mingw.bat.

Call it from any path. The script creates the build folder
"compile-mingw". Only requirement is that msvc2010-deps
is on the same level as the lyx source dir (and the C:\Qt
installation)

After the build there is a LYX_INSTALLED dir with the
files which you should pass to NSIS. If any file is
missing in LYX_INSTALLED we should fix cmake.



LyX could now build by a double click on this script.

It requires the Qt 5.5.1 at the default paths and
lyx20-deps-msvc2010-x86.zip unzipped on the same level
as the lyx sources.


I really hope this simplifies the Windows build.

Peter

Re: Windows: release with Qt 5.5.1 or 5.6?

[Peter Kümmel]

Am 13.01.2016 um 09:43 schrieb Stephan Witt:


What do others think?


Under these conditions I’d prefer the use of Qt 5.5.1 over a 5.6.0 too.


OK, I updated the batch script to use Qt 5.5.1.




Perhaps one relevant point here is that we have often released a new
minor version pretty quickly. Once 2.2.0 is out, we'll start to get bug
reports. 2.1.1 came out two and half months after 2.1.0, for example. So
we can always move to 5.6.x along the way. Obviously, we would want to
do some testing, but it would even be possible to release builds with
both 5.5.x and 5.6.x.


This is what I’ve thought too. The change of the Qt version from one
LyX patch release to another is not a real problem. But that
shouldn’t happen from beta to release version of LyX, IMO.

Stephan

Re: Windows: release with Qt 5.5.1 or 5.6?

[Peter Kümmel]

Am 13. Januar 2016 01:46:35 MEZ, schrieb Scott Kostyshak <skost...@lyx.org>:
>On Wed, Jan 13, 2016 at 01:31:59AM +0100, Peter Kümmel wrote:
>> Am 13. Januar 2016 00:32:11 MEZ, schrieb Scott Kostyshak
><skost...@lyx.org>:
>> >Dear all,
>> >
>> >There is a question of whether we should release our binary for
>Windows
>> >compiled against Qt 5.5.1 or 5.6.0.
>> >
>> 
>> It is not very complicated to switch between these two versions. So
>just let see how the timing becomes.
>
>Although I am very open since I am not knowledgeable on this topic, I
>would be quite hesitant to switch between 5.5.1 and 5.6.0 after beta. I
>am not worried about how easy it is to switch in terms of compiling
>(that is a separate set of concerns that I am not convinced are
>trivial). I'm worried about Qt bugs. I have seen many Qt bugs affect
>LyX. But I suppose we can have that discussion if the circumstances
>permit (e.g. LyX has not been released by the time Qt 5.6.0 final has
>been released, and the bug Enrico sees was fixed in Qt 5.6.0 final).


Yes, this bug looks like a show stopper for 5.6.
>
>Scott

Re: compilation problems with Qt 5.5.1 and MSVC 2010

[Peter Kümmel]

Am 13. Januar 2016 05:27:22 MEZ, schrieb "Peter Kümmel" <syntheti...@gmx.net>:
>Am 13. Januar 2016 05:19:09 MEZ, schrieb "Peter Kümmel"
><syntheti...@gmx.net>:
>>
>>>> It is a warning only committed from me today to fix a linker error.
>>>You tried it with msvc 2010? And it worked?
>>>
>>>Yes. I can now compile with MSVC 2010 and Qt 5.5.1. The compilation
>of
>>
>>>Zlib and friends works here also with MSVC2013.
>>
>>
>>Ok, then you could build an installer again with MSVC2010 and 5.5.1. 
>>
>>But afaik Qt 5.6 will not support MSVC2010 any more. So maybe it is
>>worth now to start trying with mingw, because atm the new msvc
>>compilers have no real futute within lyx. I assume even clang would be
>>better.
>>
>>Is there a recipe how to procede after the successfull build of lyx?
>>How complicated is it to get an installer created?
>>
>>The mingw.bat works, so is it possible to add a second script which
>>produces the installer?i 
>>
>>>
>>>regards Uwe

If 5.6 is to buggy, we can also use 5.5.1 build with mingw.

But when we now decide to use only msvc2010, then I stop working on a mingw 
build. 

Re: compilation problems with Qt 5.5.1 and MSVC 2010

[Peter Kümmel]

Am 13. Januar 2016 05:19:09 MEZ, schrieb "Peter Kümmel" <syntheti...@gmx.net>:
>
>>> It is a warning only committed from me today to fix a linker error.
>>You tried it with msvc 2010? And it worked?
>>
>>Yes. I can now compile with MSVC 2010 and Qt 5.5.1. The compilation of
>
>>Zlib and friends works here also with MSVC2013.
>
>
>Ok, then you could build an installer again with MSVC2010 and 5.5.1. 
>
>But afaik Qt 5.6 will not support MSVC2010 any more. So maybe it is
>worth now to start trying with mingw, because atm the new msvc
>compilers have no real futute within lyx. I assume even clang would be
>better.
>
>Is there a recipe how to procede after the successfull build of lyx?
>How complicated is it to get an installer created?
>
>The mingw.bat works, so is it possible to add a second script which
>produces the installer?i 
>
>>
>>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

MinGW: development/cmake/mingw.bat

[Peter Kümmel]

Hi Uwe, could you try development/cmake/mingw.bat.

Call it from any path. The script creates the build folder
"compile-mingw". Only requirement is that msvc2010-deps
is on the same level as the lyx source dir (and the C:\Qt
installation)

After the build there is a LYX_INSTALLED dir with the
files which you should pass to NSIS. If any file is
missing in LYX_INSTALLED we should fix cmake.

I really hope this simplifies the Windows build.

Peter

Re: compilation problems with Qt 5.5.1 and MSVC 2010

[Peter Kümmel]

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

I had to delete CMake's cache first and re-run it from scratch. The 3rd
party programs are compiled (with 134 warnings) but I don't get a DLL.
Is this the plan - not to rely anymore on DLLs?


Yes, no Dlls any more (only the Qt related ones).



thanks and regards
Uwe

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: compilation problems with Qt 5.5.1 and MSVC 2010

[Peter Kümmel]

Am 12. Januar 2016 20:24:38 MEZ, schrieb Georg Baum 
:
>Am 12.01.2016 um 00:37 schrieb Uwe Stöhr:
>> I did this now as I wrote in the
>> Questions for Uwe once you are back
>> thread.
>> I had to delete CMake's cache first and re-run it from scratch. The 
>> 3rd party programs are compiled (with 134 warnings) but I don't get a
>
>> DLL. Is this the plan - not to rely anymore on DLLs?
>>
>Almost. The libs are currently compiled as static libraries. But this
>is 
>not the most important aspect. The main goal of having these sources 
>included with LyX is that no externally compiled prerequisites are 
>needed anymore (except for qt). This has two advantages:
>
>1) It makes it more easy for other people to build LyX on windows, even
>
>if they have a different compiler than you. I hope that this will 
>attract other people who build on windows in the long term, so that you
>
>do not need to do everything alone.
>
>2) It eliminates all possibillities of errors that may occur because of
>
>different compilers. This makes it more easy for you to switch to a new
>
>MSVC version.


But Atm all msvc > 2010 versions are broken. So the only way to go is mingw or 
2010. 

>
>If it turns out that for some reason having one of these thirdparty 
>libraries as dll has advantages, we could also change the build 
>procedure to produce dlls from the same sources.
>
>
>Georg

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: compilation problems with Qt 5.5.1 and MSVC 2010

[Peter Kümmel]

Am 13. Januar 2016 01:18:12 MEZ, schrieb "Uwe Stöhr" <uwesto...@web.de>:
>Am 12.01.2016 um 11:16 schrieb Peter Kümmel:
>
>> Yes, no Dlls any more (only the Qt related ones).
>
>OK.
>
>However I get now man times this warning:
>
>D:\LyXGit\Master\compile-2010\zconf.h(10): warning C4005: 'Z_PREFIX': 
>Makro-Neudefinition [D:\LyXGit\Master\compile-2010\src\LyX.vcxproj]
>   D:\LyXGit\Master\compile-2010\config.h(78): Siehe vorherige 
>Definition von 'Z_PREFIX'
>
>Can we do something against this (MSVC 2010)?
>
>>> thanks and regards
>>> Uwe

It is a warning only committed from me today to fix a linker error. You tried 
it with msvc 2010? And it worked?

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: Windows: release with Qt 5.5.1 or 5.6?

[Peter Kümmel]

Am 13. Januar 2016 00:32:11 MEZ, schrieb Scott Kostyshak :
>Dear all,
>
>There is a question of whether we should release our binary for Windows
>compiled against Qt 5.5.1 or 5.6.0.
>

It is not very complicated to switch between these two versions. So just let 
see how the timing becomes.

>My opinion is that we should release it with 5.5.1, unless there is a
>known, significant issue that affects LyX for 5.5.1 *on Windows* and
>that would be solved with 5.6.0.
>
>There are two reasons behind my opinion. In general, I trust a point
>release more and also I do not want to depend on there not being any
>delays in the final Qt 5.6 release. The current scheduled date is
>February 9th [1]. There have been many delays in the past (e.g. the
>beta
>was delayed by more than 2 months) so I would not be surprised if there
>were more in the future. Although it is true that LyX might be delayed
>also for other reasons, we should not plan on this because that would
>cause even further delays.
>
>One reason that is against my opinion though, is that Qt 5.6 is going
>to
>be a long-term release. It is not exactly clear how this will play out
>since it is the first long-term release by Qt, from what I understand.
>However, it would indeed (if there weren't the problems I mentioned
>above) be nice to have the whole LyX 2.2.x series compiled against
>5.6.x. For example, we might be able to upgrade from 5.6.0 to 5.6.2
>from
>e.g. LyX 2.2.4 to 2.2.5 with more confidence than e.g. 5.5.1 to 5.6.2.
>However, I still think the points above outweigh this benefit.
>
>What do others think?
>
>Scott
>
>[1]
>https://wiki.qt.io/Qt-5.6-release

Re: Status on Mac with El Capitan

[Peter Kümmel]

Am 09.01.2016 um 13:12 schrieb Stephan Witt:

Am 08.01.2016 um 13:15 schrieb Kornel Benko :


Am Freitag, 8. Januar 2016 um 13:09:38, schrieb Stephan Witt 

Am 08.01.2016 um 11:53 schrieb Kornel Benko :


Am Freitag, 8. Januar 2016 um 09:10:00, schrieb Stephan Witt 

OR (maybe)
 include_directories((BEFORE
   ${TOP_SRC_DIR}/src/tex2lyx
   ${TOP_SRC_DIR}/src/support/minizip)
 include_directories(${ZLIB_INCLUDE_DIR})


Yes, this works too. BTW, what is "src/support/minizip“ for?
It doesn’t exist in the master checkout.
Why should "src/tex2lyx“ come before other includes?

Stephan


I suspected that ${ZLIB_INCLUDE_DIR} includes "/opt/local/include“.


Yes, but what’s the gain of having "src/tex2lyx“ before other includes?


Don't know. Not my doing, ask Peter. I suspected, he had a reason introducing 
it.


Peter, is the attached patch ok?


Removing the minizip should make no problems.



Stephan


I wanted to change as little as possible.


The removal of the BEFORE keyword did the job too.


Sure.

Re: Questions for Uwe?

[Peter Kümmel]

Am 09.01.2016 um 01:32 schrieb Scott Kostyshak:

On Mon, Jan 04, 2016 at 10:58:13AM -0500, Scott Kostyshak wrote:

On Mon, Jan 04, 2016 at 08:56:38AM -0500, Scott Kostyshak wrote:

On Sun, Jan 03, 2016 at 08:05:17PM +0100, Georg Baum wrote:

Scott Kostyshak wrote:


I don't understand how installers work for 32-bit vs 64-bit. Normally
does our Windows installer contain both 32-bit and 64-bit binaries? Or
we just release 32-bit and 64-bit systems are fine with it? Same for
Mac?


So far we have never released any 64bit windows binary. This is fine, since
64bit windows can execute 32bit binaries, and nobody complained yet about
LyX hitting the 32bit memory limit (around 3.5 GB on windows). I would not
switch to 64bit at this time, since this can introduce subtle bugs
(unfortunately the 64 C++ memory model differs on linux and windows, e.g.
long is 64bit on linux but 32bit on windows, so the fact that we have
working 64bit linux builds does not guarantee us working windows 64bit
builds).


I see. Thanks for the explanation. I agree we should not switch now.

Scott


Another question for Uwe. Can you still reproduce these two tickets?
http://www.lyx.org/trac/ticket/9892
http://www.lyx.org/trac/ticket/9900
That is part of the reason why I am curious about Qt 5.6.0beta1. Maybe
it makes those issues go away.

Scott


I have gone through this thread and tried to make a summary of the questions
and discussion for Uwe. Please add more questions if you have any or edit my
misinterpretation of the question/comment.

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

G=Georg
R=Richard
S=Scott

S1. Would it be reasonable to build beta1 installers with both Qt 5.5.1
and 5.6.0beta1?


There will be no downloadable msvc2010 builds for 5.6. ATM 
only 5.5.1:


http://www.qt.io/download-open-source/#section-2




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?

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




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


If Uwe tries to build the installer with the mingw build 
from the build bot, and it makes no problems, then a mingw

based installer isn't far away.



S6. 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?
That is part of the reason why I am curious about Qt 5.6.0beta1 (see question
S1). Maybe it makes those issues go away somehow.

Scott

Re: Questions for Uwe?

[Peter Kümmel]

Am 06.01.2016 um 14:23 schrieb Kornel Benko:

Am Mittwoch, 6. Januar 2016 um 14:15:22, schrieb Stephan Witt <st.w...@gmx.net>

Am 06.01.2016 um 13:35 schrieb Peter Kümmel <syntheti...@gmx.net>:




Am 03.01.2016 um 20:05 schrieb Georg Baum:


So far we have never released any 64bit windows binary. This is fine, since
64bit windows can execute 32bit binaries, and nobody complained yet about
LyX hitting the 32bit memory limit (around 3.5 GB on windows). I would not
switch to 64bit at this time, since this can introduce subtle bugs
(unfortunately the 64 C++ memory model differs on linux and windows, e.g.
long is 64bit on linux but 32bit on windows, so the fact that we have
working 64bit linux builds does not guarantee us working windows 64bit
builds).



This is the patch to build for 64bit Windows (with msvc15)

https://github.com/syntheticpp/lyx/commit/b249309e84957df512c31b3e5087fbaada681ee9


line 175 of src/support/convert.cpp is:
+string convert(unsigned ´long long ul)

Are you sure?

I cannot test - but it seems to be a wrong ´ in front of the first long.

Stephan


Is there a reason why we cannot use int64_t instead of long long?


Maybe, but long needs to be replaced by int64_t, because
long is 64bit on linux but 32bit on windows (see Georg's
answer). And this would touch many files. Additionally
we use typedef from boost which makes it more complicated.

After the 2.2 release I would require a C++11 compiler and
remove all the workarounds provided by boost.




Kornel

Re: Questions for Uwe?

[Peter Kümmel]

Am 03.01.2016 um 20:05 schrieb Georg Baum:


So far we have never released any 64bit windows binary. This is fine, since
64bit windows can execute 32bit binaries, and nobody complained yet about
LyX hitting the 32bit memory limit (around 3.5 GB on windows). I would not
switch to 64bit at this time, since this can introduce subtle bugs
(unfortunately the 64 C++ memory model differs on linux and windows, e.g.
long is 64bit on linux but 32bit on windows, so the fact that we have
working 64bit linux builds does not guarantee us working windows 64bit
builds).



This is the patch to build for 64bit Windows (with msvc15)

https://github.com/syntheticpp/lyx/commit/b249309e84957df512c31b3e5087fbaada681ee9



Georg

Re: Questions for Uwe?

[Peter Kümmel]

Am 03.01.2016 um 17:09 schrieb Kornel Benko:


It creates LyX22-2.2.0-win32.zip.
Probably not an installer like used in windows.


Yes, only the files generated my "make install".

I added "make install" to the script, and the NSIS
installer should use the files in LYX_INSTALLED/


Kornel

Re: Questions for Uwe?

[Peter Kümmel]

4. Do we also want to try releasing an installer built with mingw?
(Does that build an installer? or just LyX?)


It builds just LyX. Building an installer needs a built LyX, it should not
matter whether it was built by MSVC or mingw (except for the MSVC
prerequisites, these are not needed to be installed for mingw builds).


NSIS also runs on Ubuntu, so in principle it is possible to 
build a installer on Linux.


Peter




$ apt-cache show nsis

Package: nsis
Priority: optional
Section: universe/devel
Installed-Size: 629
Maintainer: Ubuntu Developers 


Original-Maintainer: Thomas Gaugler 
Architecture: amd64
Version: 2.46-10.1
Depends: libc6 (>= 2.14), libgcc1 (>= 1:4.1.1), libstdc++6 
(>= 4.9), zlib1g (>= 1:1.1.4), nsis-common (>= 2.46-10.1)
Suggests: nsis-doc (>= 2.46-10.1), nsis-pluginapi (>= 
2.46-10.1), mingw-w64 (>= 1.0), wine

Filename: pool/universe/n/nsis/nsis_2.46-10.1_amd64.deb
Size: 227516
MD5sum: 24da933478d7242e8d062b6bd57b2948
SHA1: 871614d709c7e5161743ddcbcded61c53843137a
SHA256: 
6239ef517d600fd977994276a28227fe3388ab39e8389df094db7a6321b1c746
Description-en: Nullsoft Scriptable Install System (modified 
for Debian)
 NSIS is a tool for creating quick and user friendly 
installers for

 Microsoft Windows (Win32) operating systems.
 .
 NSIS creates installers that are capable of installing, 
uninstalling,
 setting system settings, extracting files, etc. Because 
it's based on
 script files, you can fully control every part of your 
installers. The
 script language supports variables, functions, string 
manipulation,
 just like a normal programming language - but designed for 
the creation
 of installers. Even with all these features, NSIS is still 
the smallest
 installer system available. With the default options, it 
has an overhead

 of only 34 KB.
Description-md5: 588a1a18a7c197bf93e0bdc2aee65803
Homepage: http://nsis.sourceforge.net/
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Origin: Ubuntu

Re: Questions for Uwe?

[Peter Kümmel]

Am 06.01.2016 um 14:15 schrieb Stephan Witt:

Am 06.01.2016 um 13:35 schrieb Peter Kümmel <syntheti...@gmx.net>:




Am 03.01.2016 um 20:05 schrieb Georg Baum:


So far we have never released any 64bit windows binary. This is fine, since
64bit windows can execute 32bit binaries, and nobody complained yet about
LyX hitting the 32bit memory limit (around 3.5 GB on windows). I would not
switch to 64bit at this time, since this can introduce subtle bugs
(unfortunately the 64 C++ memory model differs on linux and windows, e.g.
long is 64bit on linux but 32bit on windows, so the fact that we have
working 64bit linux builds does not guarantee us working windows 64bit
builds).



This is the patch to build for 64bit Windows (with msvc15)

https://github.com/syntheticpp/lyx/commit/b249309e84957df512c31b3e5087fbaada681ee9


line 175 of src/support/convert.cpp is:
+string convert(unsigned ´long long ul)


Ah yes, this breaks the build. But I assumed nobody
will try and forgot to commit.
I've also not tested with mingw, so this patch is only
a hint for a build for Windows64.



Are you sure?

I cannot test - but it seems to be a wrong ´ in front of the first long.

Stephan

Re: Raspberry Pi 2 scroll speed

[Peter Kümmel]

Am 05.01.2016 um 12:28 schrieb Jean-Marc Lasgouttes:

Le 20/12/2015 15:07, Peter Kümmel a écrit :

Recently I gave away the computer which I've used when I was
very busy on LyX. It was an Athlon XP 2GHz singlecore.

I was interested how the hardware progress looks like from
the LyX perspective, means the time needed to scroll
to the end of the reference manual:


How do you scroll?


With the page-down key.





Athlon XP 2GHz: 19s (< full HD)
Haswell 4Ghz  :  8s (full HD window)
Haswell 4Ghz  :  3s (4k fullscreen)


How come that the second one is faster than the first?


I assume you mean on the Haswell system. The line width
is twice on 4k, so less pages, and it seems the pagelayout
is the expensive part.




Raspberry Pi 2: 34s (Ubuntu Mate, full HD)

Especially I was in interested in the Raspberry Pi 2 numbers,
and it looks like the Rasp could at least be used for editing
lyx files.


I suspect that this number could be improved with a bit of
profiling...

JMarc

Re: Raspberry Pi 2 scroll speed

[Peter Kümmel]

Am 06.01.2016 um 14:45 schrieb Jean-Marc Lasgouttes:

Le 06/01/2016 13:25, Peter Kümmel a écrit :



Am 05.01.2016 um 12:28 schrieb Jean-Marc Lasgouttes:

Le 20/12/2015 15:07, Peter Kümmel a écrit :

Recently I gave away the computer which I've used when I
was
very busy on LyX. It was an Athlon XP 2GHz singlecore.

I was interested how the hardware progress looks like from
the LyX perspective, means the time needed to scroll
to the end of the reference manual:


How do you scroll?


With the page-down key.


With the same repeat rate? Note that by default page down
events will be skipped when they repeat faster than painting
is done. Therefore comparison is not very easy.



Athlon XP 2GHz: 19s (< full HD)
Haswell 4Ghz  :  8s (full HD window)
Haswell 4Ghz  :  3s (4k fullscreen)


How come that the second one is faster than the first?


I assume you mean on the Haswell system. The line width
is twice on 4k, so less pages, and it seems the pagelayout
is the expensive part.


And if you try to dimension windows so that the text width
is the same?


Ah yes, didn't had idea do use a 

Is this 2.1 or 2.2? In release mode?



The one shipped by Ubuntu, so I assume some 2.1 version.


JMarc

Re: Questions for Uwe?

[Peter Kümmel]

Am 06.01.2016 um 14:35 schrieb Kornel Benko:

Am Mittwoch, 6. Januar 2016 um 14:27:24, schrieb Peter Kümmel 
<syntheti...@gmx.net>

Am 03.01.2016 um 17:09 schrieb Kornel Benko:


It creates LyX22-2.2.0-win32.zip.
Probably not an installer like used in windows.


Yes, only the files generated my "make install".

I added "make install" to the script, and the NSIS
installer should use the files in LYX_INSTALLED/



If I compile on linux, I normally do not want to install.
Or is this 'install' target something different?


cmake installs into /LYX_INSTALLED by default,
maybe even on Linux.



Kornel

Re: Questions for Uwe?

[Peter Kümmel]

Am 06.01.2016 um 13:32 schrieb Peter Kümmel:

4. Do we also want to try releasing an installer built
with mingw?
(Does that build an installer? or just LyX?)


It builds just LyX. Building an installer needs a built
LyX, it should not
matter whether it was built by MSVC or mingw (except for
the MSVC
prerequisites, these are not needed to be installed for
mingw builds).


NSIS also runs on Ubuntu, so in principle it is possible to
build a installer on Linux.



On Linux LyX.exe (and an installer I assume) could
be started with the help of Wine.


Peter




$ apt-cache show nsis

Package: nsis
Priority: optional
Section: universe/devel
Installed-Size: 629
Maintainer: Ubuntu Developers
<ubuntu-devel-disc...@lists.ubuntu.com>
Original-Maintainer: Thomas Gaugler <tho...@dadie.net>
Architecture: amd64
Version: 2.46-10.1
Depends: libc6 (>= 2.14), libgcc1 (>= 1:4.1.1), libstdc++6
(>= 4.9), zlib1g (>= 1:1.1.4), nsis-common (>= 2.46-10.1)
Suggests: nsis-doc (>= 2.46-10.1), nsis-pluginapi (>=
2.46-10.1), mingw-w64 (>= 1.0), wine
Filename: pool/universe/n/nsis/nsis_2.46-10.1_amd64.deb
Size: 227516
MD5sum: 24da933478d7242e8d062b6bd57b2948
SHA1: 871614d709c7e5161743ddcbcded61c53843137a
SHA256:
6239ef517d600fd977994276a28227fe3388ab39e8389df094db7a6321b1c746

Description-en: Nullsoft Scriptable Install System (modified
for Debian)
  NSIS is a tool for creating quick and user friendly
installers for
  Microsoft Windows (Win32) operating systems.
  .
  NSIS creates installers that are capable of installing,
uninstalling,
  setting system settings, extracting files, etc. Because
it's based on
  script files, you can fully control every part of your
installers. The
  script language supports variables, functions, string
manipulation,
  just like a normal programming language - but designed for
the creation
  of installers. Even with all these features, NSIS is still
the smallest
  installer system available. With the default options, it
has an overhead
  of only 34 KB.
Description-md5: 588a1a18a7c197bf93e0bdc2aee65803
Homepage: http://nsis.sourceforge.net/
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Origin: Ubuntu

Re: Can anyone build with mingw?

[Peter Kümmel]

Am 28.12.2015 um 14:48 schrieb Scott Kostyshak:

Ah, the cmakebin variable is not set, a rest of the bot script. Replacing the 
variable by cmake should fix it.


committed this.



Yes this was the problem. There seem to be several unset variables. Can
we use
set -u
with /bin/sh or is that only for bash?
For example, $ver is not set for me.


set -u also stops when there is a test for $1, $2, or if a 
variable is not set by design, so it could not be used.




Scott

Re: Can anyone build with mingw?

[Peter Kümmel]

Am 28. Dezember 2015 11:41:02 MEZ, schrieb Kornel Benko <kor...@lyx.org>:
>Am Montag, 28. Dezember 2015 um 05:24:59, schrieb Scott Kostyshak
><skost...@lyx.org>
>> On Mon, Dec 28, 2015 at 11:07:18AM +0100, Peter Kümmel wrote:
>> > Am 28. Dezember 2015 07:28:55 MEZ, schrieb Scott Kostyshak
><skost...@lyx.org>:
>> > >On Sun, Dec 27, 2015 at 05:52:04AM -0500, Scott Kostyshak wrote:
>> > >> Peter recently added a script to build LyX with mingw, but it
>does
>> > >not
>> > >> work for me. Does it work for anyone else?
>> > >> 
>> > >> $ ./development/cmake/scripts/xmingw
>> > >> Usage: xmingw 
>> > >> $ ./development/cmake/scripts/xmingw  ./
>> > >> -
>> > >> -- Building LyX-2015.12.27-10.49
>> > >> -
>> > >> Checking mingw installation ...
>> > >> 4.9.2
>> > >> Checking Qt installation ...
>> > >> .//../lyx-dependencies/Qt-5.5.1-i686-w64-mingw32/bin/qmake
>> > >> ./development/cmake/scripts/xmingw: line 95: ./: Is a directory
>> > >> Command failed
>> > >> $ 
>> > >> 
>> > >> It seems xmingw wants a folder as an argument, but the
>underlying
>> > >qmake
>> > >> command wants a .pro file?
>> > >
>> > >CC'ing Peter in case he doesn't follow this list.
>> > >
>> > >Scott
>> > 
>> > I only tested with an out of source build directory. Maybe it works
>in your case with an absolute path.
>> 
>> Same error:
>> 
>> $ /home/scott/lyxbuilds/master/repo/development/cmake/scripts/xmingw
>/home/scott/lyxbuilds/master/repo
>> -
>> -- Building LyX-2015.12.28-10.23
>> -
>> Checking mingw installation ...
>> 4.9.2
>> Checking Qt installation ...
>>
>/home/scott/lyxbuilds/master/repo/../lyx-dependencies/Qt-5.5.1-i686-w64-mingw32/bin/qmake
>> /home/scott/lyxbuilds/master/repo/development/cmake/scripts/xmingw:
>line
>> 95: /home/scott/lyxbuilds/master/repo: Is a directory
>> Command failed
>> $
>
>I get something different:
>$ /usr2/src/lyx/lyx-git/development/cmake/scripts/xmingw
>/usr2/src/lyx/lyx-git
>...
>Checking Qt installation ...
>/usr2/src/lyx/lyx-git/../lyx-dependencies/Qt-5.5.1-i686-w64-mingw32/bin/qmake
>/usr2/src/lyx/lyx-git/development/cmake/scripts/xmingw: 95:
>/usr2/src/lyx/lyx-git/development/cmake/scripts/xmingw:
>/usr2/src/lyx/lyx-git: Permission denied
>Command failed
>
>> Scott
>
>   Kornel

Ah, the cmakebin variable is not set, a rest of the bot script. Replacing the 
variable by cmake should fix it.

Re: [LyX/master] Add 3rdparty to source package

[Peter Kümmel]

Am 20.12.2015 um 12:31 schrieb Kornel Benko:

Am Sonntag, 20. Dezember 2015 um 12:10:19, schrieb Peter Kümmel 
<syntheti...@gmx.net>

Am 20.12.2015 um 11:29 schrieb Georg Baum:

Kornel Benko wrote:


Setting SRC_LIBCHARSET in the patch might be guarded by:
if(UNIX AND NOT MINGW)
endif()
But since I cannot test windows or Mac I don't commit.


You will see here if it compiles here:
https://travis-ci.org/syntheticpp/lyx



I'd say commit. If relocatable.c is not supposed to be compiled, then it
should be removed from the sources, these are stripped down anyway. If this
really results in an error on windows then somebody will notice.

These libs are only supposed to be built with mingw or MSVC, except
hunspell: On linux and OS X they are already provided by the OS. iconv is
even part of libc on linux. We should probably split the LYX_3RDPARTY_BUILD
switch so that the bundled hunspell can also be used independently from the
two other libs.


So which logic we should use?

1. iconv and zlib must not build on Linux
2. LYX_3RDPARTY_BUILD triggers only hunspell build and usage on Linux,
 even when there is a system version of hunspell


I committed 2.) for now.


Or is it better to disable all three libs on Linux?
Is there any benefit to use the bundled libs?


I do not see the benefit for linux ATM. But it does not harm and maybe in future
we could add some really needed 3rdparty sources.

BTW, shouldn't boost be 3rdparty too?


Yes, but I didn't want change too much at once.

But now I've moved boost to 3rdparty.
And updated to 1.60.



Peter

Re: [LyX/master] Add 3rdparty to source package

[Peter Kümmel]

Am 20.12.2015 um 11:29 schrieb Georg Baum:

Kornel Benko wrote:


Setting SRC_LIBCHARSET in the patch might be guarded by:
if(UNIX AND NOT MINGW)
endif()
But since I cannot test windows or Mac I don't commit.


You will see here if it compiles here:
https://travis-ci.org/syntheticpp/lyx



I'd say commit. If relocatable.c is not supposed to be compiled, then it
should be removed from the sources, these are stripped down anyway. If this
really results in an error on windows then somebody will notice.

These libs are only supposed to be built with mingw or MSVC, except
hunspell: On linux and OS X they are already provided by the OS. iconv is
even part of libc on linux. We should probably split the LYX_3RDPARTY_BUILD
switch so that the bundled hunspell can also be used independently from the
two other libs.


So which logic we should use?

1. iconv and zlib must not build on Linux
2. LYX_3RDPARTY_BUILD triggers only hunspell build and usage on Linux,
   even when there is a system version of hunspell

Or is it better to disable all three libs on Linux?
Is there any benefit to use the bundled libs?

Peter

Raspberry Pi 2 scroll speed

[Peter Kümmel]

Recently I gave away the computer which I've used when I was
very busy on LyX. It was an Athlon XP 2GHz singlecore.

I was interested how the hardware progress looks like from
the LyX perspective, means the time needed to scroll
to the end of the reference manual:

Athlon XP 2GHz: 19s (< full HD)
Haswell 4Ghz  :  8s (full HD window)
Haswell 4Ghz  :  3s (4k fullscreen)
Raspberry Pi 2: 34s (Ubuntu Mate, full HD)

Especially I was in interested in the Raspberry Pi 2 numbers,
and it looks like the Rasp could at least be used for editing
lyx files.

Peter

Script to cross-compile for Linux

[Peter Kümmel]

I added a script for cross-compiling for Windows.

development/cmake/scripts/xmingw

'xmingw' Must be called from a build directory with
the path to the LyX code.

Mingw needs to be installed. On Ubuntu I assume the package
gcc-mingw-w64-i686 is enough.

The script download a pre-compiled Qt 5.5.1 version, and starts
compiling.

Peter

Re: [LyX/master] Add 3rdparty to source package

[Peter Kümmel]

Am 20.12.2015 um 21:01 schrieb Pavel Sanda:

Georg Baum wrote:

Did you run configure after autogen.sh? I assume the error happens when
calling make?




Here  3rdparty/libiconv/Makefile.in  is already generated by autogen.sh.
Maybe some old files in the source tree?


Yes, also there is error when calling configure I did not catch before.
config.status: creating Makefile
config.status: creating lyx.1
config.status: creating 3rdparty/Makefile
config.status: creating 3rdparty/boost/Makefile
config.status: creating 3rdparty/hunspell/Makefile
config.status: error: cannot find input file: `3rdparty/libiconv/Makefile.in'

P

Re: [patch] Do not pretend that MSVC 12 can use dependencies compiled with MSVC 10

[Peter Kümmel]

Am 15.12.2015 um 18:34 schrieb Scott Kostyshak:

On Mon, Dec 07, 2015 at 09:53:44PM +0100, Georg Baum wrote:

First, for those who don't know, something about MSVC versions (it is easy
to get confused there):

MSVC 8: Microsoft Visual Studio 2005
MSVC 9: Microsoft Visual Studio 2008
MSVC 10: Microsoft Visual Studio 2010 Don't be mislead by the nice fit!
MSVC 11: Microsoft Visual Studio 2012 From here on we are "one off"!
MSVC 12: Microsoft Visual Studio 2013
MSVC 14: Microsoft Visual Studio 2015

Peter added a workaround for mixing code compiled by MSVC 12 and MSVC 10
some time ago:
http://www.lyx.org/trac/changeset/6b4c3036/lyxgit/ According to
https://msdn.microsoft.com/en-us/library/7sf3txa8.aspx the /vd2 option is
only needed if one wants to violate the C++ standard (using dynamic_cast on
an object being constrcuted does not work in standard conforming compilers).

I'd like to get rid of this for two reasons:

1) Mixing different MSVC versions is a bad idea as explained in the other
thread, so we should not help people to shoot themselves in the foot.

2) We cannot use dynamic_cast on not fully constrcuted objects anyway, since
we support other compilers besides MSVC.

OK to go in?


Was a decision made on this? Peter seems to be around so let's see if he
has a comment. If no one else comments, I would say please commit.

Scott



I already removed the /vd2 flag when adding the download of the new 2013 
dependencies.
But in meantime it shows that it is impossible to use msvc2013 or msvc2015:
http://www.lyx.org/trac/ticket/9892

So when someone wanna use msvc2012 he should enable the 3rdparty build,
-DLYX_3RDPARTY_BUILD=1 .

Peter

Re: Bundled 3rdparty libraries

[Peter Kümmel]

I pushed the changes, 3rdparty/ is now on the same level as src/.

It also builds on Windows with MinGW now.

The MinGW based system it's the simplest way to get a developer setup on Windows: use Qt installer from qt.io, install 
the MinGW Qt and the MinGW Compiler under Tools (same compiler version which Qt is build with), that's it. And install 
Ninja, the fastest way to build on Windows, ​https://ninja-build.org .


PATH changes with standard Qt installation on C:

set PATH=C:\Qt\5.5\mingw492_32\bin;%PATH%
set PATH=C:\Qt\Tools\mingw492_32\bin;%PATH%

Build:

cmake -GNinja ..\lyx -DLYX_USE_QT=QT5 -DLYX_3RDPARTY_BUILD=1 -DLYX_RELEASE=1
ninja
ninja install/strip

Peter

Re: use FindCXX11Compiler.cmake also for MSVC

[Peter Kümmel]

On 10.12.2015 22:48, Kornel Benko wrote:

Am Donnerstag, 10. Dezember 2015 um 21:12:36, schrieb Georg Baum 


Kornel Benko wrote:


I am a bit lost, since the small snippet below does not compile on MSVC
(for unknown reason)


template 
struct check
{
 static_assert(sizeof(int) <= sizeof(T), "not big enough");
};

typedef check right_angle_brackets;

class TestDeleted
{
public:
 TestDeleted() = delete;
};


int a;
decltype(a) b;

typedef check check_type;
check_type c;
check_type&& cr = static_cast(c);

auto d = a;

int main() {
   return 0;
};
==


It compiles with this MSVC online compiler: http://webcompiler.cloudapp.net/
According to https://msdn.microsoft.com/en-us/library/hh567368.aspx#featurelist 
it should also compile with MSVC 2013.
Earlier versions do not work because of TestDeleted.

Uwe, can you please apply the patch from Kornel in the first message in this
thread, delete CMakeCache.txt, try to build and then send me
CMakeFiles/CMakeError.log? It is too big for the list. This file will tell
us what goes wrong with the test.


Maybe also use '--debug-output' as an extra cmake parameter. Than also the file 
CMakeFiles/CMakeOutput.log may be of interest.
I'd like to have both files too.


If it compiles (with any needed compiler flags), then the last patch I
sent (in the starting mail on this thread) should be similar.

Sources changed slightly in the meantime, so the patch may not apply
cleanly. My latest guess was the flag "/Ze" to enable MSVC extensions, but
I got no response ...


Sorry, I overlooked that. /Ze is for Microsoft extensions, this is not
needed.



OK.


Georg


Kornel



Isn't this too much trouble? msvc2013 and msvc2015 have C++11 enabled by 
default.
Not much to do in the cmake files, and whan something has to be changed just use
cmake variables MSVC2012/MSVC2014. Or have I missed something?

Peter

Bundled 3rdparty libraries

[Peter Kümmel]

https://github.com/syntheticpp/lyx/commits/3rdparty

I would like to merge above Branch which adds src/3rdparty with stripped down 
sources of zlib iconv and hunspell.

Build and usage of these libs is controlled by LYX_3RDPARTY_BUILD and has been 
trdted with mingw-cross, msvc2013 and msvc2015. 

I see this as the starting point for a simpler dependency handling.

64Bit build with msvc2015

[Peter Kümmel]

Here are patches needed for a Wimdow 64 build done with msvc2015 :

https://github.com/syntheticpp/lyx/commits/msvc15-amd64

Most changes because long is only 32bit on Windows. 
http://www.viva64.com/en/t/0012/

Having a look at the tabe it seems nobody toke the coutage to make int 64 bit 
wide on 64 bit systems ;-) 

Installer with mingw build

[Peter Kümmel]

The automatic build now also builds iconv, hunspell, and zlib.

Uwe, could you check if the downloadable zip is good enough as basis for a real 
installer?

https://github.com/syntheticpp/LyX-bleeding-edge/blob/LyX-master-win32/README.md

If this works, then we could even try to build the installer automatically. 
Uwe, do you know that scripting in linux is much more convinient than these bat 
file hacking.

Or we switch mingw on Windows.

Are there any god reasons to not use mingw for a release? (sure for developing 
msvc could be still used)

Re: Unit testing

[Peter Kümmel]

Am 02.11.2015 um 21:36 schrieb Vincent van Ravesteijn:

Dear all,

I have prepared a unit test framework based on google-test (gtest). You can see 
the commits at
http://git.lyx.org/?p=developers/vfr/lyx.git;a=shortlog;h=refs/heads/tests. It 
includes gtest-1.7.0 (permitted by the
license).

Unit testing can be enabled by running CMake with -DLYX_ENABLE_UNIT_TESTS. This 
will make a target gtest-main and
unit-tests. It also create LyX.lib against which the unit testing executable is 
linked so that the functionality in the
core can be tested.

I have created a first (example) test case in tests/src/Buffer.cpp, called 
"BufferTest", which has three tests and which
is supposed to test the functionality of "lyx::Buffer".

A CMake target "unit-tests" now builds an executable running all unit-tests and 
gives an output as below. For each test
case, there is also automatically a CTest created. This test runs "unit-tests 
--gtest_filter=BufferTest" and gives a
summary. For more details, it is adviced to run the unit-tests executable 
directly (or improve CMake to capture the
output somehow).

Any comments ? Shall I proceed to push this to master ?

Vincent



Having a unit test framework integrated is a very good idea!

Why have you chosen gtest and not QTest? Does gtest has interesting
features which QTest does not have?

One benefit of QTest is that it ships with the Qt installation and
no code has to be added to the repository.

But knowing gtest (also integrating into a existing project)
is also good for other non-Qt projects.

Peter


#ctest -N
Test project C:/Users/Vincent/Documents/LyX/build/lyx/tests
   Test #1: unit_test/src/BufferTest

Total Tests: 1

#ctest -R
Test project C:/Users/Vincent/Documents/LyX/build/lyx/tests
 Start 1: unit_test/src/BufferTest
1/1 Test #1: unit_test/src/BufferTest .***Failed0.27 sec

0% tests passed, 1 tests failed out of 1

Total Test time (real) =   0.28 sec

The following tests FAILED:
   1 - unit_test/src/BufferTest (Failed)
Errors while running CTest

#unit-tests
Running main() from gtest_main.cc
[==] Running 3 tests from 1 test case.
[--] Global test environment set-up.
[--] 3 tests from BufferTest
[ RUN  ] BufferTest.NonExistingFile
[   OK ] BufferTest.NonExistingFile (0 ms)
[ RUN  ] BufferTest.NonExistingFileOperations
[   OK ] BufferTest.NonExistingFileOperations (0 ms)
[ RUN  ] BufferTest.UnicodeCharacters
..\..\..\source\gitlyx\tests\src\Buffer.cpp(45): error: Value of: string("C:/tés
t.lyx")
   Actual: "C:/t\xA8\xA6st.lyx"
Expected: fn1.absFileName()
Which is: "C:/t\xEF\xBF\xBD\xEF\xBF\xBDst.lyx"
[  FAILED  ] BufferTest.UnicodeCharacters (0 ms)
[--] 3 tests from BufferTest (0 ms total)

[--] Global test environment tear-down
[==] 3 tests from 1 test case ran. (0 ms total)
[  PASSED  ] 2 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] BufferTest.UnicodeCharacters

  1 FAILED TEST

Re: Upgrade to boost 1.59?

[Peter Kümmel]

Am 02.11.2015 um 11:40 schrieb Jean-Marc Lasgouttes:

Le 01/11/2015 16:51, Scott Kostyshak a écrit :

On Sat, Oct 31, 2015 at 11:08:51PM +0100, Peter Kümmel wrote:

Am 25.10.2015 um 06:19 schrieb Scott Kostyshak:

On Fri, Oct 23, 2015 at 06:13:03PM +0200, Vincent van Ravesteijn wrote:


I have it documented somewhere. Should I put it in development.lyx ?


If you are able to find it easily then I would say yes, please do. Even
though Peter already did the update it could be useful in the future.

Scott



Just call in boost extract.sh with the path to the new boot version,
then "git add --all", commit. That's it.


Thanks, Peter. It is good to know it is so straightforward.


Can it happen that we should remove some of the files too?


The scripts removes all existing files and adds all found by bcp.
Four files were deleted, ( git diff 04be61ea8 --name-status | grep D )

But bcp is called with these headers:

boost/any.hpp \
boost/assert.hpp \
boost/bind.hpp \
boost/crc.hpp \
boost/cstdint.hpp \
boost/format.hpp \
boost/function.hpp \
boost/functional.hpp \
boost/lexical_cast.hpp \
boost/noncopyable.hpp \
boost/regex.hpp \
boost/scoped_array.hpp \
boost/scoped_ptr.hpp \
boost/shared_ptr.hpp \
boost/signal.hpp \
boost/signals/connection.hpp \
boost/signals/trackable.hpp \
boost/tokenizer.hpp \
boost/tuple/tuple.hpp \
boost/mpl/string.hpp \
boost/mpl/fold.hpp \
boost/mpl/size_t.hpp \
boost/functional/hash.hpp \

so, when something has changed there, then we have
too much headers in our repository.



But indeed, thanks for updating.

JMarc

Re: Upgrade to boost 1.59?

[Peter Kümmel]

Using bcp from older boost releases also works, so the one from your package 
manager should be enough.
Peter 

Am 1. November 2015 17:42:51 MEZ, schrieb Vincent van Ravesteijn <v...@lyx.org>:
>On Sun, Nov 1, 2015 at 4:51 PM, Scott Kostyshak <skost...@lyx.org>
>wrote:
>> On Sat, Oct 31, 2015 at 11:08:51PM +0100, Peter Kümmel wrote:
>>> Am 25.10.2015 um 06:19 schrieb Scott Kostyshak:
>>> >On Fri, Oct 23, 2015 at 06:13:03PM +0200, Vincent van Ravesteijn
>wrote:
>>> >
>>> >>I have it documented somewhere. Should I put it in development.lyx
>?
>>> >
>>> >If you are able to find it easily then I would say yes, please do.
>Even
>>> >though Peter already did the update it could be useful in the
>future.
>>> >
>>> >Scott
>>> >
>>>
>>> Just call in boost extract.sh with the path to the new boot version,
>>> then "git add --all", commit. That's it.
>>
>> Thanks, Peter. It is good to know it is so straightforward.
>>
>> Scott
>
>It's only that simple if you have installed the bcp utility.
>
>I have made a script that automatically downloads the latest boost,
>unpacks the tar, compiles bcp, and uses it when running the extract
>script. I'll share it later.
>
>Vincent

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

Re: Compiling LyX on Windows with more recent Visual Studio versions

[Peter Kümmel]

Am 01.11.2015 um 22:02 schrieb Georg Baum:

Peter Kümmel wrote:


For iconv and hunspell one can find some CMakeLists.txt at github, not
ready for MSVC but usable as starting point. AFAIk zlib already ships
with cmake files.

Would it be an option to add tripped down iconv, hunspell and zlib sources
to lyx and to build them as static libraries like boost? Then the Windows
installer would only depend on ready-to-use binaries, maintained by other
projects.


If the license of those libs allows redistribution with the LyX sources,
then this would be an option IMHO if the size increase of the package would
not be too big. This would be easier to use than my suggestion, but in both
cases we would need somebody who keeps the sources up to date.


Georg




Hunspell:
License: GPL/LGPL/MPL tri-license.
Latest release date: 2014-06-02
http://hunspell.sourceforge.net/

libiconv:
License: GPL
Latest release date: 2011-08-07
https://www.gnu.org/software/libiconv/

zlib:
License: zlib (BSD/MIT like)
Latest release date: 2013-04-29
http://www.zlib.net/


Linking these libs into a GPL application is therefore no problem.
Sources also does not change very often, less then boost.
And the size is also not that big when only the files are
used needed to build the library.

Then I start to add the libs. Before I push I send an overview
of the changes.

Peter

Re: Compiling LyX on Windows with more recent Visual Studio versions

[Peter Kümmel]

Am 14.10.2015 um 21:52 schrieb Georg Baum:

David Hyde wrote:


I'm interested in looking into this at least a bit (may become deterred
if some dependency nightmare occurs!).  I've looked at the current MSVC
dependencies that are in the archive on sourceforge.  Which of these
are things that should actually be downloaded and compiled on the fly?


AFAIK iconv, zlib, hunspell and gettext. Unfortunately the zip file contains


JMarc said that gettext is not needed any more (there is no *getlib.lib in 
deps).

For iconv and hunspell one can find some CMakeLists.txt at github, not
ready for MSVC but usable as starting point. AFAIk zlib already ships
with cmake files.

Would it be an option to add tripped down iconv, hunspell and zlib sources
to lyx and to build them as static libraries like boost? Then the Windows
installer would only depend on ready-to-use binaries, maintained by other
projects.


a mixture of different kinds of dependencies: The ones I mentioned are
needed for compiling LyX, the others like python and ghostscript are for
building the installer or running LyX. In my initial answer I did not think
of the latter. I believe that we do not need to do much about these, since
you can always simply install the latest version of these tools.


  For example, do you think that Python and ghostscript should be
compiled from source, or do you think it suffices to just include up-to
-date Windows binaries?  Same question goes for other deps I think.
  Based on your feedback I can try to hack around with this a bit and
see what I can get working with the latest MSVC.


Very nice! Don't hesitate to ask if you've got any question, the worst thing
that can happen is that nobody knows (unlikely).


Georg

Re: Minimum compiler version

[Peter Kümmel]

Am 29.10.2015 um 20:17 schrieb Georg Baum:


BTW, I wanted to try the cross-compiling myself for several montsh now,
because I am curious, but did not find the time up to now.


The build-bot already cross-compiles for Windows, it is NOT a Windows machine.
Recently travis updated their bots to to Ubuntu LTS 14.04 und I changed the
scripts to use mingw-w64 shipped by Ubuntu.

So when you clone
https://github.com/syntheticpp/lyx.git
and checkout the branch 'bleeding-edge-master', install mingw-w64
(have a look at .travis.yml) then a simple call of
./development/cmake/scripts/travis.sh
starts the cross-compliation of lyx.

(It does not work on Ubuntu 15.04.)




Georg

Re: Upgrade to boost 1.59?

[Peter Kümmel]

Am 25.10.2015 um 06:19 schrieb Scott Kostyshak:

On Fri, Oct 23, 2015 at 06:13:03PM +0200, Vincent van Ravesteijn wrote:


I have it documented somewhere. Should I put it in development.lyx ?


If you are able to find it easily then I would say yes, please do. Even
though Peter already did the update it could be useful in the future.

Scott



Just call in boost extract.sh with the path to the new boot version,
then "git add --all", commit. That's it.

Peter

Re: Build bot reactivated

[Peter Kümmel]

Am 24.10.2015 um 20:25 schrieb Uwe Stöhr:

Am 24.10.2015 um 07:26 schrieb Peter Kümmel:


Do you think the warning is too extreme?


No, this is sadly true. Just replacing LyX files will break
LyX's functions. One need to set the PATH prefix in LyX etc.
to keep it running. So it OK to warn people.


Clearly, it would be better to build the complete installer,
but I'm not sure if it is worth the effort, especially
because Uwe is working mainly on Windows.


Well, I can now grab your build and bundle an installer for
LyX 2.2 alpha based on Qt 5.5. But note that there is a
nasty bug in Qt 5.5 on Windows which forces us to wait for
Qt 5.6.


Tanks, but not worth the effort.
And I will disable it again because it's only a waste
of electric energy if not a real installer is created.



many thanks Peter and best regards
Uwe

Re: Minimum compiler version

[Peter Kümmel]

Am 25.10.2015 um 20:31 schrieb Georg Baum:

Vincent van Ravesteijn wrote:


I thought we always wanted to support as many compilers as reasonably
possible in order to allow newcomers to easily compile LyX and to let
them contribute. Does it make sense to still support Qt 4.5, but to
require the last version of the Microsoft compiler ?


BTW I do not think that Qt 4.5 needs to be supported. One could also discuss
in principle whether support for MSVC2010 is needed, or whether we could
require 2012.

The most important reason to support C++98 in 2.2.0 is IMHO that a change so
fundamental as to switch from one standard version to another is always a
risky thing, and doing it immediately before a release is the worst timing
one could have. These changes need to be done in the development branch
directly after a stable release in order to get more experience. This is not
pure theory, simply by compiling in C++11 mode we did already find a bug in
a mature, well reputed compiler:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67557 Who tells us that there
is not another one hidden (maybe in another compiler)?



Very interesting bug, even if the code looks a bit strange.

In another project I saw speed improvements just
by enabling C++11 (I assume mainly because of the
move semantic).




Since we need to support C++98 anyway it is also clear that MSVC 2010 should
not be dropped. This eases the work of the windows people a lot: No new
dependencies are required right now, and nobody needs to learn a new version
(remember that MSVC is not only a compiler, but an IDE).


I would even support MSVC only for developers and do the
release with MinGW, would simplify compiling all the 
dependencies a lot.



Finally, supporting C++98 for 2.2.0 does not cost us anything right now,
since no biger changes will happen before the release anyway, and the
existing code supports C++98. Also, those who want to compile in C++11-mode
can do so as well if they are willing to accept a higher risk. If the case
happens that backporting a bugfix to 2.2.x will be difficult (as mentioned
by Guillaume), then we can still see how to solve that problem at the time
when it happens. IMHO, a backporting difficulty caused by the need to
support the old standard is in no way different from a backporting
difficulty caused by some code refactoring. In both cases, one needs to
assess the importance of the bug fix, the cost of it and its risk. Then one
can decide whether to do it or not.


Georg

Minimum compiler version

[Peter Kümmel]

I wonder to still see auto_ptr:

https://travis-ci.org/syntheticpp/lyx

Which old compiler you wanna support?

Peter

Re: Upgrade to boost 1.59?

[Peter Kümmel]

Am 23.10.2015 um 18:13 schrieb Vincent van Ravesteijn:


Op 23 okt. 2015 17:37 schreef "Jean-Marc Lasgouttes"
>:
 >
 > I think we should upgrade our local copy of boost to 1.59
before alpha (or at least before beta).
 >
 > Is the procedure documented somewhere?
 >
 > Also, what can we do to hide the warnings related to
auto_ptr? If we are out of ideas, I propose to compile with
-Wno-deprecated-functions in C++11 mode.
 >
 > JMarc

I have it documented somewhere. Should I put it in
development.lyx ?

Vincent



I could do it. I've done it already multiple times.

Peter

(a little, little back ;)

Build bot reactivated

[Peter Kümmel]

I've reactivated the build-bot for Windows binaries of the 
master branch. It uses GCC 4.8.2 and Qt 5.5.1 (32 bit).


http://syntheticpp.github.io/LyX-bleeding-edge

Maybe it helps a bit for 2.2.

Peter

Re: Minimum compiler version

[Peter Kümmel]

Am 23.10.2015 um 20:55 schrieb Guillaume Munch:

Le 23/10/2015 17:55, Peter Kümmel a écrit :

I wonder to still see auto_ptr:

https://travis-ci.org/syntheticpp/lyx

Which old compiler you wanna support?

Peter




Dear Peter,


See
<http://mid.gmane.org/326d2a33-d65f-488d-9bc3-5331535a4...@lyx.org>

and subsequent messages. The only concrete example was
Jean-Marc's OSX 10.7 computer, although in this case there is a
straightfoward fix according to Google.



Hi Guillaume,

I assume GCC on this system is very old, but Xcode also 
ships with clang, which supports


"The LLVM compiler now supports C++11 'user defined 
literals' and 'unrestricted unions' features."


https://developer.apple.com/library/watchos/documentation/DeveloperTools/Conceptual/WhatsNewXcode/Articles/xcode_4_0.html#//apple_ref/doc/uid/TP40016147-SW5

so maybe using clang is an option.



Another argument in favour of keeping C++98 seemed to be that
backporting from C++11 to C++98 is supposed to be effortless
(which makes me wonder why C++11 was at all invented). However the
discussion about allowing Unicode string literals clearly showed the
contrary:  <http://mid.gmane.org/mv8skg$jb7$1...@ger.gmane.org>.

The overall discussion about C++11 was rather unconvincing,
and as a consequence I have already decided to use C++11 features
without restraint starting from 2.3, and not to make a single
non-trivial effort at possible backports into 2.2 of any of my patches. One
cannot claim one day that LyX is short in developer time, and another day
that increasing backporting efforts is without consequences. This
makes me hope that this 2.2 version will be short-lived (however
impatient I am to see it out).


Then backporting is an argument to require c++11 already for 
2.2.


Peter





Guillaume

Re: Build bot reactivated

[Peter Kümmel]

Am 23.10.2015 um 21:07 schrieb Richard Heck:

On 10/23/2015 12:52 PM, Peter Kümmel wrote:

I've reactivated the build-bot for Windows binaries of the
master branch. It uses GCC 4.8.2 and Qt 5.5.1 (32 bit).

http://syntheticpp.github.io/LyX-bleeding-edge

Maybe it helps a bit for 2.2.


You should add a warning that using those binaries could
melt you monitor and has also been found to cause cancer in
laboratory rats. ;-)


Do you think the warning is too extreme?

Clearly, it would be better to build the complete installer,
but I'm not sure if it is worth the effort, especially
because Uwe is working mainly on Windows.

Peter



Richard

Re: Minimum compiler version

[Peter Kümmel]

Am 23.10.2015 um 21:16 schrieb Vincent van Ravesteijn:

Guillaume


Well, I probably can wake you from your dreams of C++11
quickly when I try compiling your C++11 features with
MSVC2010...




Vincent