[Scummvm-devel] Clarifying & cleaning configure's cross-compiling craziness

[Max Horn]

Hi Klaus,

thanks for the update!


Am 04.05.2011 um 16:24 schrieb Klaus Reimer:

> On 05/04/2011 02:38 PM, Max Horn wrote:
>> Well, there is more, but just take a glance at the gist
>> <https://gist.github.com/955116>, search for "TODO", and then reply
>> to this email if you like.
> 
> Let me answer the webos questions:

Thanks!

> 
>> webos also overrides datarootdir, datadir, docdir -- why?
> 
> The structure of the ScummVM files of webOS port is like this:
> 
>  com.github.kayahr.scummvm/
>    bin/
>    lib/
>    data/
>    doc/

I see. This is a bit similar to the Mac OS X (and iPhone) bundles, which have a layout like this:
  ScummVM.app/
    Contents/
      MacOS/  (similar to bin)
      Resources/ (similar to data)
      ...

[...]
> 
> The installation of the files is done in the webos.mk file and I could
> simply ignore docdir and change the install parameters

This is what we do for Mac OS X and iPhone bundles, and probably also for other similar things in other ports. (Android comes to mind here; I don't think it uses datadir etc. either, but I could be wrong).

> but the datadir
> is more problematic because this variable is also used by ScummVM to
> find the place where to search for themes and dat files.

I assume you are referring to DATA_PATH, which is used in exactly one spot: OSystem_SDL::addSysArchivesToSearchSet.

This is a virtual method, though, specifically to allow overriding this / setting more appropriate default paths. E.g. for the Mac OS X port, there is OSystem_MacOSX::addSysArchivesToSearchSet, which uses special Mac OS X APIs to correctly locate the "Resources/" folder, in a way that works regardless of where the ScummVM binary was placed and how it was called (from the command line or from Finder).

So now I am wondering: Is the absolute path to ScummVM on WebOS always fixed? Are applications not relocatable there? If not, then I guess setting a value for DATA_PATH is most convenient for you. But maybe there are special APIs to locate the resource / data directories of the active app. In that case, you may want to overload addSysArchivesToSearchSet in your port, instead of using DATA_PATH.


> I know there
> are configuration keys for setting the theme path and extras path but in
> my opinion it is better when the paths in the binary are already correct
> and don't need to be corrected by the scummvmrc.

Of course, fully agreed. The only question is how the default is set. Your current way is OK for that, and might even be the best, depending on how WebOS exactly works -- and of course you are the one who should determine this :).

If the result is that the current approach (which tweaks datadir, docdir etc.) is indeed the best, then I am fine with keeping it -- but then please add a comment to it that briefly explains the rationale behind it, as you did here, so that future generations will understand, too :).


> 
> Another alternative is specifying --datadir and --docdir parameters on
> every build but then this must be hardcoded in the buildbot which is
> even worse.

Agreed, that would not be a good "solution". Sensible defaults are very important, and we don't want to make it needlessly complicated to setup a cross compile environment.

> 
> If there is a better way to do it, please let me know. It would be nice
> to be able to specify platform specific defaults for these paths so it
> is still possible to override them with configure parameters. But the
> platform is only known after parsing the configure parameters and then
> the default values are already set.

I guess you meant "..., and then the user overrides for the paths have already been set" here? Because that seems to be the real problem, we do things this way:
1) set defaults for various *dir variables
2) parse user params, override host/backend, but possibly also *dir variables

So after step 2, we know the backend. We can now modify the *dir variables based on that, but this could overwrite whatever tweaks the user made. Possible solutions:

a) don't care about that ("there is only one sensible way to set these anyway")
  -> In that case, though, why even bother using the *dir variables anyway;
     just hardcode the right paths in your 'install' make target etc.

b) Handle the default values for the various *dir vars differently
   That is, mimic what we do for _debug_build: Initially, it is set to "auto".
   Then, *after* processing the command line, we set the defaults, but only for
   those *dir values that still equal "auto" (or maybe some other, more funky value,
   in case somebody is concerned that users might want to use "auto" as a dir name... :)

c) split the command line parsing:
   1) first scan for backend / host params; 
   2) now allow backends / host specific code to tweak defaults
   3) now scan for all other params

Doing a) is easiest, doing b) matches what we do for other stuff already; if we were to implement c), then we might want to adapt all things that use approach c) right now. But b) has the advantage that it is less strict on where one has to set the default values; with c), it must be between the two command line processing steps, with b) it can be essentially anywhere. And it feels kinda artificial to split the command line processing up, doesn't it?

> 
> 
>> TODO: All (?) SDL based ports run find_sdlconfig here -- except for
>> the WebOS and WinCE ports -- why? shouldn't they also use
>> find_sdlconfig?
> 
> There is no sdl-config in the WebOS PDK which can be used for
> cross-compiling. There is one which contains wrong paths and includes
> MacOS X framework libraries and which is therefor unusable for
> cross-compiling. That's why I'm ignoring it. I could fix this script but
> then it will only work on buildbot and on my own systems. Don't think
> that's a good idea.

I see, makes sense -- and once more, please document this in configure.


Cheers,
Max