Re: [Wesnoth-dev] Re: Static Build on Mac OS X

[ott]

On Fri, Jun 17, 2005 at 09:37:31AM +0100, Fairydreams (General) wrote:
> This is not how a well behaved Mac application works, hence the data  
> was moved. This should be kept for as long as the target audience are  
> Mac users rather than Mac developers.
[...]
> Trying to make the *application* identical for all users is a  
> retrograde step.

Just to clarify: the target audience for the commandline build is very
clearly Mac developers.  The idea for me is to ensure that I am running
as similar a system as possible to the other devs, so I can help with the
mainstream of bug fixing activity, instead of fighting with differences
due to the platform.

However, I would also like to move the Xcode and default commandline
builds closer.  Right now, there are simple things that are duplicated,
and that don't need to be.  An example is building the translations, which
can be automated much better using a simple standalone script extracted
from the current makefile -- this could be called in the makefile as
well as by the IDE project files, reducing the duplication of effort.

To my mind, ensuring the "base" build works on Mac OS X is a necessary
part of easing the job of anyone trying to build a native app with
additional platform specific functionality.  We seem to be tackling
parts of the same problem, just from different perspectives.

> An external editor can still access all  
> files within a bundle, after all a bundle is still a folder.

In theory, yes.  In practice -- how do you suggest a separate Map Editor
application goes about trying to find the Wesnoth application, so it can
find the game data inside the bundle?

> The editor was in even worse shape  
> for the Mac and broke so often that I considered it easier to write a  
> new version in Cocoa than keep the standard one running.

Understood.  However, the map editor has been pretty functional for
a while now.  The exception is its lack of support for the global
hotkeys (so it needs Ctrl as the modifier key instead of Cmd).  The map
editor really needs to have this, and some other issues (like broken
translations, custom terrains breaking the editor), fixed.

> Some of the extra functionally added in the MacOS X version is to  
> make it a well behaved Mac application.

It would be great if this could be taken further.  Right
now the Mac OS X application doesn't seem to support
being hidden using Cmd-H or quitting using Cmd-Q.  See
https://savannah.nongnu.org/bugs/?func=detailitem&item_id=9432 for
the original bug report (marked as Postponed by Dave).  It shares this
behaviour with the barebones app as built using wesnoth_bundle.

> As for the future, Wesnoth should always be buildable with XCode as  
> that is the official development platform on the Mac. If it could be  
> compiled by the command line too, then excellent.

Agreed completely.  Right now the commandline build is much easier
than the Xcode build, since it can essentially be automated into a
straightforward script, once fink is installed.  If the Xcode project
file in CVS were brought up to date, it would again be easier to build
using Xcode.  The current version seems very old?

My ideal would be to see the default configure/make build use lists of
files stored in external files instead of file lists being assigned
to variables, and these assignments being scattered across several
makefiles.  Such lists could be used to generate the Xcode dependency
list automatically.  Then the Xcode project could be kept up to date
with the default build without any files needing to be added or deleted
manually, it would just work.  I'm not familiar with the Microsoft build
environment but in principle this would apply there also.

> Relying on Fink for developer tools is fine. There is no problem with  
> them having to jump through extra hoops. Just be careful not to add  
> extra Fink dependencies (i.e. on Fink versions of libraries used) as  
> there could be a danger of building in Fink dependency in the final  
> app which would be a disaster for MacOS X users.

This is precisely what I am trying to avoid, and it looks like a
semi-static build may be the only realistic way to do it.  The alternative
is to bundle all the required dynamic libraries inside the application
bundle (in the form of frameworks), as you currently do with your Mac
OS build.  This is a problem for the commandline build since the SDL
framework packages from libsdl.org do not package the sdl-config script,
and this is currently an absolute requirement for a successful configure
run.  On the other hand, the fink SDL libraries seem to have all sorts of
hidden dependencies -- things like libpng, various Ogg Vorbis components,
even QuickTime.

> Personally I think the core issue is far less what we do with  
> libraries, but far more how old a version of MacOS X we intend to  
> support. There is a large amount of effort in supporting 10.2.8 and  
> in some cases this can actually make the application more unstable.

Would a semi-static binary as I described support a wider range of
operating system versions?

-- address@hidden