Re: [Wesnoth-dev] Integrating the xcode files to compile on osx into cvs?

[ott]

On Sun, Apr 17, 2005 at 08:46:57PM -0500, Richard Kettering wrote:
> The kicker is - he's the only one who CAN do the maintenance on this, 
> since he is the exclusive source of those files (someone else could of 
> course make their own version, essentially forking them, but that would 
> be silly).

Several people, including Sanna, Crimson Penguin and myself, have XCode
project files to build BfW, forked off the common base of Sithrandel's
XCode project file from a few releases ago.  Currently these project
files all refer to Sithrandel's additional Cocoa files, and therefore
Sithrandel is really the right person to maintain this file.

However, we could also consider an XCode project file to build BfW as
a commandline app without the Cocoa bits.  It should be quite simple to
create a new project file for this.  This file would have to be maintained
in parallel with the configure/Makefile system used for most platforms,
similar to the way the VC++ project file is maintained by David.

Instead of using XCode to maintain a set of code dependencies in parallel
with the official configure/Makefile system, I've found it simpler to
just use the standard commandline build, and to provide feedback when
changes to the build process breaks the commandline build on Mac OS X.
For instance, the requirement for a recent Freetype 2 broke my build,
and I provided a simple workaround by defining the macros that were not
present in older Freetype distributions (like the one that ships with
Mac OS X 10.3).  If we really want to support XCode, I think it would
be possible to create a trivial XCode project file which just calls
configure and make to do all the work.

To better support Mac OS X, we thus need to choose between pure
commandline (which already works fine), commandline-with-XCode-wrapper
(would need to be created), XCode-emulating-configure-make (would need to
be created) and XCode plus significant additions (as already maintained
by several people).

The real issue here is that Sithrandel's code adds a lot of bits and
pieces onto the core distribution.  Some of these are necessary for the
application to be properly integrated in a Mac environment: for instance,
by providing application icons, allowing the application to be launched
from the Finder by double clicking it (something the vanilla commandline
build does not support), and supporting commandline arguments in an app
that is launched by double clicking.  Some of Sithrandel's additions
are interesting but probably unnecessary, like installing user campaigns
by drag-and-dropping them onto the application.  Some additions provide
new functionality, such as the campaign editor.  Finally, some additions
provide alternative ways of doing things, like the build only supporting
the map editor function in the campaign editor instead of the standard
map editor.  (Note that the map editor works fine as a commandline app
on Mac OS X.)

On the other hand, not even Sithrandel's build supports the Cmd-H
shortcut to hide the application, or even Cmd-Q to quit, and these would
be prerequisites if we want the application to conform to the Mac OS X
interface guidelines.

To summarise, we have some bits that should be added to the core codebase,
like handling commandline arguments and launching from the Finder.
We have bits that perhaps do not need to be (drag-and-drop and campaign
editor), and which are written using the Mac-only Cocoa framework.
Finally, we have bits that should be but which do not exist, like a
proper map editor build (unless Sanna has managed to get this to work),
and better support for the user interface guidelines.

The first category should be integrated into the existing build process.
Ideally we do need to build an application that behaves the way people
expect Mac applications to behave, that is supports launching by double
clicking an icon in the Finder.  This requires some but not all of the
code from Sithrandel's Cocoa files to be integrated into the project.
The third category is pretty important also.  I would prefer if the
second category stays out of the core codebase, since it does not fit
with the ethos of the rest of the project, which has cross platform
support as a core value.

Other than Sithrandel, we don't have any programmers who are familiar
with the Mac OS X idiom, so any Mac OS X specific additions depend
completely on Sithrandel.  Sithrandel -- over to you.  :-)

-- address@hidden