Re: Could not determine MSC version (Visual Studio 2017)

On 24/01/2019 21:04, julien2412 wrote:
> Here what I did to avoid language pb:
> export LANG=C
> make clean
> make
>
> Here are the last lines:
> [build ULF]
> C:/BLP/libo-core/workdir/ScpMergeTarget/scp2/source/writer/registryitem_writer.ulf
> [build ULF]
> C:/BLP/libo-core/workdir/ScpMergeTarget/scp2/source/winexplorerext/module_winexplorerext.ulf
> [build MO ] sdfr
> [build MO ] sfxfr
> [build ULF]
> C:/BLP/libo-core/workdir/CustomTarget/shell/source/win32/shlxthandler/res/shlxthdl.ulf
> [build MO ] smfr
> [build MO ] svlfr
> [build MO ] svtfr
> [build MO ] svxfr
> [build MO ] swfr
> [build MOD] ucbhelper
> [build MO ] uuifr
> [build MO ] vclfr
> [build PRP] CustomTarget/wizards/locproperties/resources_fr.properties
> [build PRP] CustomTarget/wizards/locproperties/resources_qtz.properties
> [build MO ] wizfr
> [build MO ] wptfr
> [build MO ] xscfr
> [build PAT] libxslt
> [build UIC] modules/dbapp
> make[2]: warning: -jN forced in submake: disabling jobserver mode.
> expr: syntax error
> expr: syntax error
> expr: syntax error
> checking build system type... x86_64-unknown-cygwin
> checking host system type... x86_64-unknown-cygwin
> checking target system type... x86_64-unknown-cygwin
> checking for cl... cl
> configure: error: Could not determine MSC version.
> make[2]: *** [Makefile:129: ../nspr/out/config.status] Error 1
>
> It seems it's quite at random since the build runned a longer time.

From "make[2]: *** [Makefile:129: ../nspr/out/config.status] Error 1" 
it looks like this is a failure during configure of external/nss. 
workdir/UnpackedTarball/nss/nspr/out/config.log might contain a clue as 
to why it fails for you.

> I'll try "make -O" tomorrow.

Always use -O.  It doesn't make any difference for failing vs. not 
failing, it just makes sure that the output from recipes that make runs 
in parallel don't all write to the same stdout/stderr in parallel.  Not 
using -O leads to garbled output, making it hard to tell which make 
target exactly failed in what way.
> remarks:
> - building with Cygwin was taking a lot memory (I got 8GB) and, contrary to
> Linux building, I saw a lot of "include file" in console. (perhaps both are
> linked)

Those "include file" lines should be from invoking cl with /showincludes 
(which we use for dependency tracking, similar to GCC -MD).  No idea why 
they (or at least lots of them) show up on stdout/stderr for you, though.

> - also when using Ctrl-C on cygwin to stop the process then close cygwin, it
> seems it doesn't stop process and so doesn't free memory ; ie I could see
> several "make" process on tasks manager.

Yes, that's a well-known issue.