Re: [ww-tedit-dev] Moving to cmake

[Tzvetan Mikov]

On 9/25/06, petar marinov wrote:
> > On the other hand one problem with cmake is that compiling languages
> > which it doesn't support directly is very verbose. Take this
> > expression to compile a Bison file:
> >
> > ADD_CUSTOM_COMMAND(
> >  SOURCE p1-parse.y DEPENDS p1-parse.y OUTPUT p1-parse.tab.c p1-parse.tab.h
> >  COMMAND bison ARGS -v -d p1-parse.y
> >  WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
> > )
> >
> > I am still a cmake newbie; perhaps there is a better way. In any case,
> > cmake feels a little like Ant - it is very convenient for C, but is
> > clumsy for other things.
>
> I couldn't figure some stuff about cmake myself and that's why I bought
> the book about cmake.

(Did you really have time to read it ?)
So, do you have an idea about how to do a bison/flex invocation
better/easier/shorter ? That would be really helpful (and we will use
it in ww too if we decide to use cmake).

> What do you think about these options:
> 1) ask people to download free visualC7
> 2) ask people to install the standalone gnu _make_ for windows
> 3) ask people to install mingw which will optionally be able to compile
> with visualC (I don't know what is inside mingw, I believe it includes
> make which we can use both for mingw and _cl_)

My point is the following: ideally build alternatives should be clear-cut.
If you want to build with cygwin, use Cygwin.
If you want to build with mingw, use mingw.
If you want to build with VisualC, use VisualC.

You shouldn't have to mix them. For a user there is absolutely no
point in building with VisualC if he already has mingw or Cygwin. So,
ideally a VisualC build shouldn't require anything that isn't already
in VisualC.

Of course cmake isn't packaged with VisualC, which complicates things.
We have to look from a different angle.

First of all, we want to use the same "build-script" (be it Makefile,
CMake, SCons, etc) for all platforms. This rules out manually writing
a Win32 NMAKE file. This also means that it won't be possible to
perform a build only with the VisualC package, leaving us with only
two remaining choices.

* cmake.
Pros:
- Much simpler build script (no need for manual dependency checking, etc)
- Unifies the platform-specific configuration and build. No external
tools, shell scripts, utilities are needed on any platform.
- Can generate a VC project file.
Cons:
- Requires a 3.5MB download on Win32.
- It isn't clear how to make crosscompiles (but it is possible)

* gmake
Pros:
- We already have a gmake Makefile (but it uses Unix utilities)
- Some things (e.g. flex) appear to be easier compared to CMake
Cons:
- Requires a 3.5 MB download from here: http://unxutils.sourceforge.net/
- Doesn't solve the configuration problems. Configuration requires
executing shell scripts, etc, which are very difficult to get working
outside of a complete emulation environment like Cygwin (or MSYS)
- Cross-compiles are possible, but not supported by the current
Makefile and will complicate it significantly.

(I have ruled out options like Cygwin and Mingw, since they are
obviously impractical for a "casual" build)

The decisive point for me is the configuration and shell utilities. WW
doesn't currently do per-paltform configuration, but it should - it
feels awkward to build compared to "native" Unix applications, the
build often breaks mysteriously, there is no "make install", etc.
Additionally, the Makefile uses tools like sed, etc, which is a major
pain to configure and install on Win32 if it is done only for the
purpose of building ww.

The least painful choice at this point, which still improves the
situation compared to what we have now, is to use CMake. We don't have
to view it is a final decision - the current Makefile will be archived
- we can always go back to pure gmake. I think it is worth a try.

On another subject: I have serious trouble using WW with the numpad
keys not working properly - do you have any idea about that bug ?

-tz