Build script error on Windows

[bohrshaw]

I couldn't build with .\nmake.bat on Windows with a probably proper build environment. I asked for help at http://talk.commonmark.org/t/help-building-cmark-on-windows/1881 and @jgm suggested me to report an issue instead.

I was able to built it successfully with the following steps:

1. I made some edits to "Makefile.nmake".

   diff --git a/Makefile.nmake b/Makefile.nmake
   index b0556e2..e4124a6 100644
   --- a/Makefile.nmake
   +++ b/Makefile.nmake
   @@ -7,7 +7,7 @@ PROG=$(BUILDDIR)\src\cmark.exe
   GENERATOR=NMake Makefiles
   
   all: $(BUILDDIR)
       -   @cd $(BUILDDIR) && $(MAKE) /nologo && cd ..
       +   @cd $(BUILDDIR) && $(MAKE) /nologo /f ..\Makefile.nmake && cd ..
   
       $(BUILDDIR):
           @-mkdir $(BUILDDIR) 2> nul
           @@ -20,7 +20,7 @@ $(BUILDDIR):
               cd ..
   
               install: all
               -   @cd $(BUILDDIR) && $(MAKE) /nologo install && cd ..
               +   @cd $(BUILDDIR) && $(MAKE) /f ..\Makefile.nmake /nologo install && cd ..
   
               clean:
               -rmdir /s /q $(BUILDDIR) $(MINGW_INSTALLDIR) 2> nul
               @@ -29,7 +29,7 @@ $(SRCDIR)\case_fold_switch.inc: $(DATADIR)\CaseFolding-3.2.0.txt
               perl mkcasefold.pl < $? > $@
   
               test: $(SPEC) all
               -   @cd $(BUILDDIR) && $(MAKE) /nologo test ARGS="-V" && cd ..
               +   @cd $(BUILDDIR) && $(MAKE) /f ..\Makefile.nmake /nologo test ARGS="-V" && cd ..
   
               distclean: clean
               del /q src\scanners.c 2> nul
   

2. I ran .\nmake.bat and got:

   ...
   cd build &&  cmake  -G "NMake Makefiles"  -D CMAKE_BUILD_TYPE=  -D CMAKE_INSTALL_PREFIX=windows  .. &&  cd ..
   -- Configuring done
   -- Generating done
   -- Build files have been written to: D:/Workspaces/cmark/build
   NMAKE : fatal error U1052: file '..\Makefile.nmake' not found
   Stop.
   NMAKE : fatal error U1077: 'cd' : return code '0x2'
   Stop.
   NMAKE : fatal error U1077: 'cd' : return code '0x2'
   Stop.
   

3. I supposed at least the build files are generated successfully.
   I then reverted the change to "Makefile.nmake" and ran .\nmake.bat again. This time it succeeded.

So it seems the build script is not robust or not correct.

[jgm]

The build script assumes that if there is a 'build'
directory, it has successfully populated with build
files by cmake.

If the build directory is created but (e.g.) cmake
isn't present, and so these files aren't created in
build, then the build script would fail. (This might
have happened if, for example, you ran the build
script, then it failed and you realized you needed
cmake, which you then installed.)

So, I suggest you try the following:

• delete the build subdirectory
• revert all your edits to Makefile.nmake (reset the
  repository to its original state)
• Now try nmake again

nmake works just fine on our appveyor.com builds.

If this works, then I think all we need is a more
robust recovery from the case where build exists
but wasn't fully or properly created.

[bohrshaw]

If this works, then I think all we need is a more
robust recovery from the case where build exists
but wasn't fully or properly created.

Yes it works! In this case, we may create the build directory after detecting cmake; and prompt suggestions to delete the build directory should the build directory exist and the build failed.

By the way, in Powershell, we should run .\nmake instead of nmake, which could be mentioned in the README.

[jgm]

I have made a small change which would have prevented the
problem you have. We now look for build/CMakeFiles rather
than just build. If build is created but cmake doesn't
exist, build/CMakeFiles will still be missing, so it will
try again.

A more ambitious change would be to explicitly check
for cmake before creating any directories. The main
Makefile does that, as you can see -- if you'd like to
port the logic over to Makefile.nmake, be my guest.
(I don't know what I'm doing when it comes to Windows
and don't have a Windows build environment to test in,
other than appveyor.)

[tin-pot]

@bohrshaw (and @jgm actually too ;-)
If you want, you could use (rsp pull from) my clone of cmark — it has VC++ 9.0 (Visual Studio 2008) project files in the VC9 directory. The project files build (without the use of cmake):

• A static library libcmark.lib, containing the translator code itself,
• an executable cmark.exe, the reference implementation's main program,
• an executable cm2html.exe, which generates HTML documents (hopefully conforming to ISO 15445:2000).

I had to "massage" the sources a bit so that a pre-C99, dumb compiler like VC 9.0 can grok them, but otherwise (as far as I can remember) the translator itself is not changed.

I have merged the jgm/cmark repository into my clone just two hours ago, so the CommonMark reference implementation parts should be up to date ...

The cm2html HTML output contains the repository URL and commit ID in a <meta> element like this:

  <META name="GENERATOR"
        content="cmark 0.22.0 (git@github.com:tin-pot/cmark.git a288e7744d90)">

These are created from macros REPOURL and GITIDENT, defined in the header files repourl.h and gitident.h, which in turn are generated in a pre-build action in the cm2html.vcproj project setting, using git ls-remote rsp git show-ref (just in case you miss these two header files in the repository).

[jgm]

@tin-pot I'd rather stick with the current cmake build system. It should be capable of handling MSVC, and is regularly tested on Windows. If it's not able to handle certain older versions, let us know the details and we can improve the build system.

[tin-pot]

Well, I did not intend to replace the current build system using cmake and scripts. Building directly from VS project files from inside the IDE works -- better -- for me, though.

If I remember correctly, I didn't even try to use the build system: Clobbering together some project files to build a "simple" command-line program seemed easier to me. And I had the wish to place the parser in a (static) library, which it isn't in the current build process (?) -- in order to build multiple tools using the same parser.

So I can't really say much about how well or bad the cmake-based build works on Windows ... Let me know if me trying this out is important for you ...

The little stumbling blocks in the sources itself (regarding pre-C99 compilers) have been ironed out, thanks to your help, and that is what is important for me.

(Isn't cmake even supposed to generate .vcproj files and all, for MSVC? [Grabs documentation and exits ...])

[jgm]

Yes, cmake will generate VS project files.
Try (using a fresh checkout of cmark)

mkdir build
cd build
cmake -G "Visual Studio 9 2008" ..

and see what it gives you. I haven't tried this myself,
as I don't even have Visual Studio. But others have, I
believe -- though perhaps not for that old a version.

+++ Martin Hofmann [Oct 18 15 14:17 ]:

Well, I did not intend to replace the current build system using cmake
and scripts. Building directly from VS project files from inside the
IDE works -- better -- for me, though.

If I remember correctly, I didn't even try to use the build system:
Clobbering together some project files to build a "simple" command-line
program seemed easier to me. And I had the wish to place the parser in
a (static) library, which it isn't in the current build process (?) --
in order to build multiple tools using the same parser.

So I can't really say much about how well or bad the cmake-based build
works on Windows ... Let me know if me trying this out is important for
you ...

The little stumbling blocks in the sources itself (regarding pre-C99
compilers) have been ironed out, thanks to your help, and that is what
is important for me.

(Isn't cmake even supposed to generate .vcproj files and all, for MSVC?
[Grabs documentation and exits ...])

—
Reply to this email directly or [1]view it on GitHub.

References

1. Build script error on Windows #85 (comment)

[tin-pot]

Thanks, I'll try to use the cmake build the other day (it's not that I hadn't used cmake before, just not for my own stuff at home). And when I'm at it, I'm better going to attempt adding my clone's setup (one library, two executables) into a cloned CMakeLists.txt definitions. May take some days, though.

I'll come back to you if I run into problems, ok?