Hmm, you may be right. I've looked more closely at the script and there
are some things still wrong, e.g. "deploy" option is not implemented but
advertised as a command line option. I admit, I don't like the fact that
the script needs to be edited either.
If there is interest in this, I am willing to revamp this script to do a
proper build + install and properly treat arguments with no editing of
the script required -- either pass paths as options or use a small conf
file. That way new versions of the script can always be pulled.
Granted, a makefile should pretty much do all that (is this what you
were referring to?).
Bogdan.
On 15-Jun-12 10:04 am, Bogdan Roman wrote:
On 15-Jun-12 9:41 am, Vincent van Ravesteijn wrote:
Op 15-6-2012 9:47, Bogdan Roman schreef:
Correct patch attached. Sorry for the previous wrong one.
Bogdan.
On 15-Jun-12 8:18 am, Bogdan Roman wrote:
I just spent a while to make this work. I documented all changes in
Evernote here: http://bit.ly/MafHMA (has an updated build.bat and patch
too). Below is a plain-text version.
Changes to the INSTALL.Win32 file (May 27, 2012 version from Git) which
I had to make to compile LyX:
-- Where to put ninja.exe (the CMakeScript you downloaded)? I placed it
in p:\CMake\2.8\bin\ where I installed CMake but it still caused an
error when doing "build devel", see below.
-- Changes to build.bat from \development\cmake\
- cmake was not found so the "set PATH" line in my case had to be
changed to:
set PATH=P:\Qt\4.8.1\bin;p:\CMake\2.8\bin;%PATH%
- you do not need to set GNUWIN32_DIR or LYX_SOURCE (the build.bat
script detects them automatically)
- ninja compilation did not work for me (CMake error: Could not
create named generator Ninja) so I had to remove -GNinja from the
"cmake" line
- the line "cd %LYX_BUILD%" needs to be changed to
cd /d %LYX_BUILD%
because %LYX_BUILD% might point to a different drive than the one
holding the source files (my case), and then cd alone won't change dir
and will creates a mess as the "Debug" gets created in the same folder
as the sources. *I think* that the /d of "cd /d" is available from
WinXP
onwards. If that's the case then on Win2k you may do first
"%~dLYX_BUILD:" to change the drive before doing "cd %LYX_BUILD%".
-- There are several other errors in the INSTALL.Win32 file
- at point 8. and 9. there is suddenly "lyx-20-install", which
sould probably read "lyx-20-build"
- for the debug/devel build, the dependency dir
"msvc2010-deps\deps20\bin" from 7. should not actually be copied to
"lyx-20-build\bin\Debug" but rather the files from
"msvc2010-deps\deps20\bin" should be copied into
"lyx-20-build\bin\Debug". Otherwise you get an error when executing
LyX.exe that it can't find certain dlls.
-- Previously (when using SVN, i.e. before Git) I had to download
doxygen (here) and add it to PATH before/while using CMake GUI. I
already had it when switching to the new cmake build.bat so I'm not
sure
if this is still needed.
Attached is a modified build.bat and patch.
Why don't you use CMake directly ? That's the recommended way to compile
LyX on Windows.
Where's that recommendation? Right now the recommended way I see is the
INSTALL.Win32 file and other info pointing to it. CMake GUI was used in
the SVN era iirc, and it was quite cumbersome, having to manually fix
several configure stages. Ifyou're suggesting I use cmake from the
command line then why wouldn't I want to automate the arguments? The
*nix scripts do ...
This build.bat script is maintained by and tailored for a single
developer only and your patch is just making it work for you, but this
won't work in general. I vote for removing this script from the
repository completely.
The patch and comments are fixing general issues. Of course it will work
in general; the user needs to edit the paths to qmake/build-dir/etc as
indicated in the install.win32 file. With my changes then the script
will actually work when doing "build devel" or "build install" rather
than running into errors several times.
The script is useful, I wouldn't remove it. I would actually enhance it
so that the dependency files, Qt dlls, etc are copied automatically to
the correct debug/release locations after msbuild completes without
errors, rather than having to do that manually. Then it will be a true
one-liner, similar to the *nix builders. I'll test this and submit a
patch soon.
Bogdan.
