[bug] Compiling vim.exe fails

[Axel Bender]

Compiling vim.exe (Windows 7 64-bit, MinGW 64-bit) fails with:

gcc -c -Iproto -DWIN32 -DWINVER=0x0500 -D_WIN32_WINNT=0x0500 -DHAVE_PATHDEF -DFEAT_BIG -DMS_WIN64 -DHAVE_GETTEXT -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT -DFEAT_OLE -DFEAT_CSCOPE -DFEAT_MBYTE -DFEA
T_MBYTE_IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -w -march=x86-64 -Wall -Id:/tools/perl/lib/Core -DFEAT_PERL -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DDYNAMIC_PERL -DDYNAMIC_PERL_DLL=\"pe
rl522.dll\" -DFEAT_PYTHON -DDYNAMIC_PYTHON -DDYNAMIC_PYTHON_DLL=\"python27.dll\" -O3 -fomit-frame-pointer -freg-struct-return -s os_win32.c -o objx86-64/os_win32.o
os_win32.c: In function 'mch_start_job':
os_win32.c:5102:1: error: label at end of compound statement
failed:
^
Make_cyg_ming.mak:852: recipe for target 'objx86-64/os_win32.o' failed
make: *** [objx86-64/os_win32.o] Error 1

[Mike Williams]

diff --git a/src/os_win32.c b/src/os_win32.c
--- a/src/os_win32.c
+++ b/src/os_win32.c
@@ -5101,8 +5101,9 @@ mch_start_job(char *cmd, job_T *job)

failed:
# ifdef FEAT_CHANNEL
- channel_free(channel);
+ channel_free(channel)
# endif
+ ;
}


Come on guys, if you're fixing code dependent on pp defines, check with
them both defined and undefined that everything still builds and links.

Mike
--
This is certainly more fun than being hit with a hammer.

[Bram Moolenaar]

It appears Appveyor only builds one specific setup. It would be useful
to run a few more combinations. I can't possibly check more than a few
things, especially if it involves MS-Windows (with at least four
combinations: GUI/console * MSVC/MingW).

Anyway, I prefer the solution I sent in the patch with #else. A bit
easier to see what's happening.

--
hundred-and-one symptoms of being an internet addict:
261. You find diskettes in your pockets when doing laundry.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Christian Brabandt]

Hi Bram!

We test building 32 and 64bit vim.exe when creating the
vim-win32-installer once a day. We could possibly add more features
using a matrix. But I think it makes sense to test this using the
regular appveyor tests. What features should we add there for testing?


Best,
Christian
--
Die Aläutischen Inseln wohnen in Erdhütten. Ihre Fenster sind oben; eigentlich haben
sie gar keine Fenster.
-- Johann Georg August Galletti

[Bram Moolenaar]

This should not be part of the daily build but the one that's triggered
by a submit. Then we get a warning email five minutes later.

The one we currently have only tests the GUI. We should at least have
one that builds the console version.

Also having at least one for MingW seems necessary, since it produces
different warnings and errors than MSVC.

We'll never catch everything, but we can try to catch the most common
problems. So long as we don't run out of capacity on Appveyor.

--
hundred-and-one symptoms of being an internet addict:

263. You have more e-mail addresses than shorts.

[Mike Williams]

On 15/02/2016 12:09, Bram Moolenaar wrote:
>
> Mike Williams wrote:

>> Come on guys, if you're fixing code dependent on pp defines, check with
>> them both defined and undefined that everything still builds and links.
>
> It appears Appveyor only builds one specific setup. It would be useful
> to run a few more combinations. I can't possibly check more than a few
> things, especially if it involves MS-Windows (with at least four
> combinations: GUI/console * MSVC/MingW).

The only combination relevant here is if FEAT_CHANNEL is defined or not.
If someone writes code that depends on a PP symbol I would hope they
would check compiles with it defined and undefined. They should not be
relying on a CI server to catch these basic mistakes IMHO. (Sorry, it's
a Monday.)

> Anyway, I prefer the solution I sent in the patch with #else. A bit
> easier to see what's happening.

Technically, it is not to keep the compiler happy but to write correct C
code. There is a reason why goto has a bad reputation. ;-)

TTFN

[Christian Brabandt]

Hi Bram!

On Mo, 15 Feb 2016, Bram Moolenaar wrote:

> This should not be part of the daily build but the one that's triggered
> by a submit. Then we get a warning email five minutes later.

That's what I meant.

>
> The one we currently have only tests the GUI. We should at least have
> one that builds the console version.
>
> Also having at least one for MingW seems necessary, since it produces
> different warnings and errors than MSVC.
>
> We'll never catch everything, but we can try to catch the most common
> problems. So long as we don't run out of capacity on Appveyor.

Okay, here we go. This builds MVC (64bit) and mingw 32bit versions on
appveyor with all feature switches (gvim and vim.exe). The huge versions
is build with python enabled. This should catch most of the obvious
#ifdef errors we have seen lately.

The patch already contains some #ifdefs, needed to fix some errors.
Unfortunately, I haven't seen it build completely yet, due to some
errors and the current fast development cycle.

Some of the errors and warnings reported here on the list are also shown
in the current logs, e.g.
https://ci.appveyor.com/project/chrisbra/vim-ch0ci/build/job/ag948fmsdkuv4dok#L307
https://ci.appveyor.com/project/chrisbra/vim-ch0ci/build/job/ag948fmsdkuv4dok#L344
https://ci.appveyor.com/project/chrisbra/vim-ch0ci/build/job/ag948fmsdkuv4dok#L362
https://ci.appveyor.com/project/chrisbra/vim-ch0ci/build/job/ag948fmsdkuv4dok#L397
https://ci.appveyor.com/project/chrisbra/vim-ch0ci/build/job/ag948fmsdkuv4dok#L438

However, since this builds MSVC and Mingw gvim and vim.exe for
FEATURES=tiny, small, normal, big and huge and runs the test it will
take a while to finish, probably around 50 Minutes.

Feedback appreciated.

Best,
Christian

[Ken Takata]

Hi Christian,

I don't think the following hunk should be applied:

--- a/src/os_win32.c
+++ b/src/os_win32.c
@@ -5175,8 +5175,10 @@ mch_stop_job(job_T *job, char_u *how)
return TerminateProcess(job->jv_proc_info.hProcess, 0) ? OK : FAIL;
}

+#ifndef __MINGW32__
if (!AttachConsole(job->jv_proc_info.dwProcessId))
return FAIL;
+#endif
ret = GenerateConsoleCtrlEvent(
ctrl_c ? CTRL_C_EVENT : CTRL_BREAK_EVENT,
job->jv_proc_info.dwProcessId)

MinGW is too old now. We should use MinGW-w64 (MSYS2) instead.
MinGW-w64 is available on the following path on AppVeyor:

32 bit target: C:\msys64\mingw32\bin
64 bit target: C:\msys64\mingw64\bin

Regards,
Ken Takata

[mattn]

> > However, since this builds MSVC and Mingw gvim and vim.exe for
> > FEATURES=tiny, small, normal, big and huge and runs the test it will
> > take a while to finish, probably around 50 Minutes.
> >
> > Feedback appreciated.
>
> I don't think the following hunk should be applied:

> MinGW is too old now. We should use MinGW-w64 (MSYS2) instead.

> MinGW-w64 is available on the following path on AppVeyor:
>
> 32 bit target: C:\msys64\mingw32\bin
> 64 bit target: C:\msys64\mingw64\bin

Should we get it with LoadLibrary/GetProcAddress?

- mattn

[Ken Takata]

Hi,

2016/2/17 Wed 18:00:10 UTC+9 Ken Takata wrote:
> I don't think the following hunk should be applied:
>
> --- a/src/os_win32.c
> +++ b/src/os_win32.c
> @@ -5175,8 +5175,10 @@ mch_stop_job(job_T *job, char_u *how)
> return TerminateProcess(job->jv_proc_info.hProcess, 0) ? OK : FAIL;
> }
>
> +#ifndef __MINGW32__
> if (!AttachConsole(job->jv_proc_info.dwProcessId))
> return FAIL;
> +#endif
> ret = GenerateConsoleCtrlEvent(
> ctrl_c ? CTRL_C_EVENT : CTRL_BREAK_EVENT,
> job->jv_proc_info.dwProcessId)
>
>
> MinGW is too old now. We should use MinGW-w64 (MSYS2) instead.
> MinGW-w64 is available on the following path on AppVeyor:

Or, how about setting WINVER to 0x0501? (Currently it is 0x0500.)

Regards,
Ken Takata

[Bram Moolenaar]

Thanks. Not sure if it's all that useful to build all five feature
sets. huge + normal for GUI and console covers quite a bit already.

It seems the reltime test is a bit flaky. Perhaps also caused by giving
AppVeyor so much work.

--
ZOOT: I'm afraid our life must seem very dull and quiet compared to yours.
We are but eightscore young blondes, all between sixteen and
nineteen-and-a-half, cut off in this castle, with no one to protect us.
Oooh. It is a lonely life ... bathing ... dressing ... undressing ...
making exciting underwear....
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

[Christian Brabandt]

On Mi, 17 Feb 2016, Bram Moolenaar wrote:

> Thanks. Not sure if it's all that useful to build all five feature
> sets. huge + normal for GUI and console covers quite a bit already.
>
> It seems the reltime test is a bit flaky. Perhaps also caused by giving
> AppVeyor so much work.

Okay, updated patch attached. Thanks also to Ken for his information
regarding MSYS2. I changed it accordingly. Last build log can be seen
here:
https://ci.appveyor.com/project/chrisbra/vim-ch0ci

This builds a FEATURE=HUGE and FEATURE=NORMAL mingw 32bit gvim and MVC
64bit gvim and vim.exe (with python enabled for the huge version and
runs the test with the MVC gvim). I think that should cover most of what
you want. I left some comments in there, so you can easily enable the
other feature sets.

Best,
Christian
--
Die gängige Moral will stets unterdrücken.
-- Bertrand A. W. Russell

[Bram Moolenaar]

Christian Brabandt wrote:

> On Mi, 17 Feb 2016, Bram Moolenaar wrote:
>
> > Thanks. Not sure if it's all that useful to build all five feature
> > sets. huge + normal for GUI and console covers quite a bit already.
> >
> > It seems the reltime test is a bit flaky. Perhaps also caused by giving
> > AppVeyor so much work.
>
> Okay, updated patch attached. Thanks also to Ken for his information
> regarding MSYS2. I changed it accordingly. Last build log can be seen
> here:
> https://ci.appveyor.com/project/chrisbra/vim-ch0ci
>
> This builds a FEATURE=HUGE and FEATURE=NORMAL mingw 32bit gvim and MVC
> 64bit gvim and vim.exe (with python enabled for the huge version and
> runs the test with the MVC gvim). I think that should cover most of what
> you want. I left some comments in there, so you can easily enable the
> other feature sets.

Thanks. I think we should also build a console version. Since testing
appears to the take bulk of the time we can run the tests once with
HUGE-console features. So perhaps we can build TINY-console with MSVC
and HUGE-console with MingW and then run the tests with the MingW
binary? That way we cover more rows & columns in the build & test
matrix.

Perhaps the build can be made faster by not using -O3. -O2 should be
sufficient to get useful warnings. Even -O1 should be enough and quite
a bit faster.

--
GALAHAD: No look, really, this isn't nescess ...
PIGLET: We must examine you.
GALAHAD: There's nothing wrong with ... that.

[Christian Brabandt]

On Mi, 17 Feb 2016, Bram Moolenaar wrote:

> Thanks. I think we should also build a console version. Since testing
> appears to the take bulk of the time we can run the tests once with
> HUGE-console features. So perhaps we can build TINY-console with MSVC
> and HUGE-console with MingW and then run the tests with the MingW
> binary? That way we cover more rows & columns in the build & test
> matrix.

Well, a console version is build for MSVC, since that appears to build
faster than MingW. Testing happens with the gvim.exe build from MSVC,
because first of all, the test I tried with MingW did stall on test47
and second of all, last time I checked with the nightly windows builds,
the gui version test was a lot faster than the console test.

> Perhaps the build can be made faster by not using -O3. -O2 should be
> sufficient to get useful warnings. Even -O1 should be enough and quite
> a bit faster.

I did change that. Now MingW builds with -O2 which is indeed quite
faster and I believe it did generate some more warnings.
https://ci.appveyor.com/project/chrisbra/vim-ch0ci/build/47

Updated patch attached.

Best,
Christian
--
Nichts gibt Frauen eine königlichere Haltung als das Bewußtsein, daß
sie ihr Alter besiegt haben.
-- Arthur Schnitzler (Aphorismen und Betrachtungen aus dem Nachlaß)

[Bram Moolenaar]

Christian Brabandt wrote:

> On Mi, 17 Feb 2016, Bram Moolenaar wrote:
>
> > Thanks. I think we should also build a console version. Since testing
> > appears to the take bulk of the time we can run the tests once with
> > HUGE-console features. So perhaps we can build TINY-console with MSVC
> > and HUGE-console with MingW and then run the tests with the MingW
> > binary? That way we cover more rows & columns in the build & test
> > matrix.
>
> Well, a console version is build for MSVC, since that appears to build
> faster than MingW. Testing happens with the gvim.exe build from MSVC,
> because first of all, the test I tried with MingW did stall on test47
> and second of all, last time I checked with the nightly windows builds,
> the gui version test was a lot faster than the console test.

Running the tests in the console is different from running them in the
GUI, I think we should run both.

If a test stalls then we may have to skip it. We already skip several
tests for MS-Windows, either they are omitted in the Makefile or the
test bails out early.

I'm surprised the console tests are slower, the GUI has to open a new
window, create menus, etc. Perhaps it's because console I/O is being
slow.

> > Perhaps the build can be made faster by not using -O3. -O2 should be
> > sufficient to get useful warnings. Even -O1 should be enough and quite
> > a bit faster.
>
> I did change that. Now MingW builds with -O2 which is indeed quite
> faster and I believe it did generate some more warnings.
> https://ci.appveyor.com/project/chrisbra/vim-ch0ci/build/47

Hmm, I would expect fewer warnings. Looks like they are easy to fix
though.

> Updated patch attached.

This builds four versions and tests two? I do think we also want
MingW-console and MSVC-GUI.

--
"Intelligence has much less practical application than you'd think."
-- Scott Adams, Dilbert.

[Christian Brabandt]

On Do, 18 Feb 2016, Bram Moolenaar wrote:

> Christian Brabandt wrote:
> > On Mi, 17 Feb 2016, Bram Moolenaar wrote:
> >
> > > Thanks. I think we should also build a console version. Since testing
> > > appears to the take bulk of the time we can run the tests once with
> > > HUGE-console features. So perhaps we can build TINY-console with MSVC
> > > and HUGE-console with MingW and then run the tests with the MingW
> > > binary? That way we cover more rows & columns in the build & test
> > > matrix.
> >
> > Well, a console version is build for MSVC, since that appears to build
> > faster than MingW. Testing happens with the gvim.exe build from MSVC,
> > because first of all, the test I tried with MingW did stall on test47
> > and second of all, last time I checked with the nightly windows builds,
> > the gui version test was a lot faster than the console test.
>
> Running the tests in the console is different from running them in the
> GUI, I think we should run both.

Okay, we can do this. Will take longer however.

> If a test stalls then we may have to skip it. We already skip several
> tests for MS-Windows, either they are omitted in the Makefile or the
> test bails out early.

This only happened for the tiny version. Interestingly, it does not
stall, when I run it locally. Hm, let's see, if WINVER=0x501 as Ken
suggested fixes this. Also the tiny mingw version stalled at compiling
here:
https://ci.appveyor.com/project/chrisbra/vim-ch0ci/build/48/job/2ayvxobvq80uc551
,----
| mingw32-make.exe -C GvimExt -f Make_ming.mak CROSS=no CROSS_COMPILE= CXX='g++' STATIC_STDCPLUS=no
| mingw32-make.exe[1]: Entering directory 'C:/projects/vim-ch0ci/src/GvimExt'
| g++ -O2 -DFEAT_GETTEXT -c gvimext.cpp -o gvimext.o
| windres --preprocessor="g++ -E -xc" -DRC_INVOKED --input-format=rc --output-format=coff -DMING gvimext_ming.rc -o gvimext.res
| g++ -shared -O2 -s -o gvimext.dll \
| -Wl,--enable-auto-image-base \
| -Wl,--enable-auto-import \
| -Wl,--whole-archive \
| gvimext.o gvimext.res gvimext_ming.def \
| -Wl,--no-whole-archive \
| -luuid -lgdi32
| mingw32-make.exe[1]: Leaving directory 'C:/projects/vim-ch0ci/src/GvimExt'
`----
Don't know, why this is happening.

(a little bit later...)
Hm, no does not help. The tiny version still stalls there:
https://ci.appveyor.com/project/chrisbra/vim-ch0ci/build/job/fb8s0g2umwldgrue

Also, latest mingw version still shows some warnings:
https://ci.appveyor.com/project/chrisbra/vim-ch0ci/build/55/job/nbyergs228easqat#L127

And since we are at it, the console version fails:
https://ci.appveyor.com/project/chrisbra/vim-ch0ci/build/55/job/nbyergs228easqat#L2538
https://ci.appveyor.com/project/chrisbra/vim-ch0ci/build/55/job/nbyergs228easqat#L4062
https://ci.appveyor.com/project/chrisbra/vim-ch0ci/build/55/job/nbyergs228easqat#L4157
https://ci.appveyor.com/project/chrisbra/vim-ch0ci/build/55/job/nbyergs228easqat#L4662
https://ci.appveyor.com/project/chrisbra/vim-ch0ci/build/55/job/nbyergs228easqat#L4666
https://ci.appveyor.com/project/chrisbra/vim-ch0ci/build/55/job/nbyergs228easqat#L4670

> I'm surprised the console tests are slower, the GUI has to open a new
> window, create menus, etc. Perhaps it's because console I/O is being
> slow.

Yes, it is veeery slow. One Feature Set test (building gvim and vim
versions for MingW and MSVC and Testing MingW vim.exe and MSVC gvim.exe)
now takes about 20 Minutes. Hm, perhaps, we should add some time stamps,
before the test starts.

>
> > > Perhaps the build can be made faster by not using -O3. -O2 should be
> > > sufficient to get useful warnings. Even -O1 should be enough and quite
> > > a bit faster.
> >
> > I did change that. Now MingW builds with -O2 which is indeed quite
> > faster and I believe it did generate some more warnings.
> > https://ci.appveyor.com/project/chrisbra/vim-ch0ci/build/47
>
> Hmm, I would expect fewer warnings. Looks like they are easy to fix
> though.
>
> > Updated patch attached.
>
> This builds four versions and tests two?

Building gui Mingw, gui MSVC and console MSVC each for huge and normal
feature set. The huge feature set also enables CHANNEL and PYTHON
version.

> I do think we also want MingW-console and MSVC-GUI.

Okay. Updated patch attached.


Mit freundlichen Grüßen
Christian
--
Das sogenannte "verkannte Genie" ist eine zweifelhafte Erscheinung.
Meist entpuppt es sich als Untauglichkeit.
-- Carl Gustav Jung

[Christian Brabandt]

On Do, 18 Feb 2016, Christian Brabandt wrote:
> And since we are at it, the console version fails:

[...]

This was the test of Mingw vim.exe 7.4.1352

Best,
Christian
--
Der Kaiser belohnte ihn königlich.
-- Heinz Erhardt

[Bram Moolenaar]

Christian Brabandt wrote:

> On Do, 18 Feb 2016, Bram Moolenaar wrote:
>
> > Christian Brabandt wrote:
> > > On Mi, 17 Feb 2016, Bram Moolenaar wrote:
> > >
> > > > Thanks. I think we should also build a console version. Since testing
> > > > appears to the take bulk of the time we can run the tests once with
> > > > HUGE-console features. So perhaps we can build TINY-console with MSVC
> > > > and HUGE-console with MingW and then run the tests with the MingW
> > > > binary? That way we cover more rows & columns in the build & test
> > > > matrix.
> > >
> > > Well, a console version is build for MSVC, since that appears to build
> > > faster than MingW. Testing happens with the gvim.exe build from MSVC,
> > > because first of all, the test I tried with MingW did stall on test47
> > > and second of all, last time I checked with the nightly windows builds,
> > > the gui version test was a lot faster than the console test.
> >
> > Running the tests in the console is different from running them in the
> > GUI, I think we should run both.
>
> Okay, we can do this. Will take longer however.

I'm glad you are taking the time to make this work. Pity it's not that
easy. I see the current version still fails in some ways it would not
fail when run locally.

> > If a test stalls then we may have to skip it. We already skip several
> > tests for MS-Windows, either they are omitted in the Makefile or the
> > test bails out early.
>
> This only happened for the tiny version. Interestingly, it does not
> stall, when I run it locally. Hm, let's see, if WINVER=0x501 as Ken
> suggested fixes this. Also the tiny mingw version stalled at compiling
> here:
> https://ci.appveyor.com/project/chrisbra/vim-ch0ci/build/48/job/2ayvxobvq80uc551

Also see some warnings there. Let me know if you see more (so long as
it's predictable how to fix them :-).

It appears to get stuck in "windres". Perhaps it's showing a dialog and
wants you to click OK. Hmm, the "Leaving directory" indicates that
windres finished, thus it must be something else.

The tiny build should probably not build GvimExt. And the console
version should not build it either.

--
"To whoever finds this note -
I have been imprisoned by my father who wishes me to marry
against my will. Please please please please come and rescue me.
I am in the tall tower of Swamp Castle."
SIR LAUNCELOT's eyes light up with holy inspiration.

"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

[Christian Brabandt]

Hi Bram!

On Fr, 19 Feb 2016, Bram Moolenaar wrote:

>
> Christian Brabandt wrote:
>
> > On Do, 18 Feb 2016, Bram Moolenaar wrote:
> >
> > > Christian Brabandt wrote:
> > > > On Mi, 17 Feb 2016, Bram Moolenaar wrote:
> > > >
> > > > > Thanks. I think we should also build a console version. Since testing
> > > > > appears to the take bulk of the time we can run the tests once with
> > > > > HUGE-console features. So perhaps we can build TINY-console with MSVC
> > > > > and HUGE-console with MingW and then run the tests with the MingW
> > > > > binary? That way we cover more rows & columns in the build & test
> > > > > matrix.
> > > >
> > > > Well, a console version is build for MSVC, since that appears to build
> > > > faster than MingW. Testing happens with the gvim.exe build from MSVC,
> > > > because first of all, the test I tried with MingW did stall on test47
> > > > and second of all, last time I checked with the nightly windows builds,
> > > > the gui version test was a lot faster than the console test.
> > >
> > > Running the tests in the console is different from running them in the
> > > GUI, I think we should run both.
> >
> > Okay, we can do this. Will take longer however.
>
> I'm glad you are taking the time to make this work. Pity it's not that
> easy. I see the current version still fails in some ways it would not
> fail when run locally.

Yes, I saw some test failures for the console version. Attached patch
appveyor_test_fixes.diff fixes those warnings (basically by making sure,
that VIMRUNTIME is defined) and disables 2 tests, for which I couldn't
find out, why they failed.
Also, this patch fixes a warning about an uninitialized variable in
f_tan()

> It appears to get stuck in "windres". Perhaps it's showing a dialog and
> wants you to click OK. Hmm, the "Leaving directory" indicates that
> windres finished, thus it must be something else.
>
> The tiny build should probably not build GvimExt. And the console
> version should not build it either.

Hm, I don't know how to disable this. However, I left out the tiny
version and the current version only builds normal and huge versions as
requested.

Attached patch appveyor_test_matrix does that.


Best,
Christian
--
Daß uns der Anblick der Tiere so ergötzt, beruht hauptsächlich darauf,
daß es uns freut, unser eigenes Wesen so vereinfacht vor uns zu sehn.
-- Arthur Schopenhauer

[Bram Moolenaar]

I don't think using "set" works with nmake:

set VIMRUNTIME=..\..\runtime && $(VIMPROG) -u NONE -U NONE -S runtest.vim $*.vim

I don't understand why you need this, Vim should be able to find the
runtime files relative to the executable.

> > It appears to get stuck in "windres". Perhaps it's showing a dialog and
> > wants you to click OK. Hmm, the "Leaving directory" indicates that
> > windres finished, thus it must be something else.
> >
> > The tiny build should probably not build GvimExt. And the console
> > version should not build it either.
>
> Hm, I don't know how to disable this. However, I left out the tiny
> version and the current version only builds normal and huge versions as
> requested.
>
> Attached patch appveyor_test_matrix does that.

--
ARTHUR: A scratch? Your arm's off!
BLACK KNIGHT: No, it isn't.
ARTHUR: Well, what's that then?
BLACK KNIGHT: I've had worse.
The Quest for the Holy Grail (Monty Python)

[Christian Brabandt]

I don't either exactly and I cannot reproduce the problems locally, so I
was toying
around appveyor and find a way to fix it. The original problem can be
seen here:

https://ci.appveyor.com/project/chrisbra/vim-ch0ci/build/56/job/tvp5gjh3kxttotja#L4647

From test_quickfix.vim:
Found errors in Test_helpgrep():
Caught exception in Test_helpgrep(): Vim(helpgrep):E480: No match:
quickfix @ function Test_helpgrep, line 1

From test_syntax.vim:
Found errors in Test_syn_iskeyword():
Caught exception in Test_syn_iskeyword(): Vim(source):E484: Can't open
file C:/projects/vim-ch0ci/src/testdir\syntax\syntax.vim @ function
Test_syn_iskeyword, line 8

From test_alot.vim:
Found errors in Test_load_menu():
function Test_load_menu line 4: 'error while loading menus:
Vim(source):E484: Can''t open file
C:/projects/vim-ch0ci/src/testdir/menu.vim'
TEST FAILURE
NMAKE : fatal error U1077: 'if' : return code '0x1'
Stop.
Command exited with code 2

Which looks like, Vimruntime isn't set or empty or something. An
alternative solution would be to
set vimruntime in the testfiles, that failed. I'll send a patch later.


Best,
Christian

[Bram Moolenaar]

The output of :version should tell you if there is a fall-back for
$VIMRUNTIME. If it's not set, then check the Makefile, in Make_mvc.mak
it's done around line 1323. However, the default is empty.

It should work to find the runtime files relative to the binary. This
happens in vim_getenv(), around line 4320 in misc1.c. No idea why this
would not work in this setup.


--
LAUNCELOT: I am, sir. I am a Knight of King Arthur.
FATHER: 'Mm ... very nice castle, Camelot ... very good pig country....

"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

[Christian Brabandt]

On Di, 23 Feb 2016, Bram Moolenaar wrote:

> The output of :version should tell you if there is a fall-back for
> $VIMRUNTIME. If it's not set, then check the Makefile, in Make_mvc.mak
> it's done around line 1323. However, the default is empty.
>
> It should work to find the runtime files relative to the binary. This
> happens in vim_getenv(), around line 4320 in misc1.c. No idea why this
> would not work in this setup.

Ah, it was a user error. Updated patch attached.
I think the patch is now ready to be included.

Just to recap:

This builds for Huge and Normal Feature Set a console and gui version
(the huge version with +python/dyn and +python3/dyn) using MSVC and
MingW.

The test then runs with the MSVC gvim and the MingW console version (for
both huge and normal versions).

Best,
Christian

[Bram Moolenaar]

Thanks. I'll probably include it tomorrow.

--
The war between Emacs and Vi is over. Vi has won with 3 to 1.
http://m.linuxjournal.com/files/linuxjournal.com/linuxjournal/articles/030/3044/3044s1.html