[Scummvm-devel] Ports and their custom build systems. Do we need them?

Marcus Comstedt marcus at mc.pp.se
Mon Oct 19 23:26:34 CEST 2009


Max Horn <max at quendi.de> writes:

>> [...]
>>> I guess there may be errors in the supported engines table, but for
>>> example I think several ports are distributing the Igor engine  
>>> enabled
>>> by default (which isn't stable yet), and the PS2 had several stable
>>> engines disabled until a few hours ago.
>>
>> I don't see what this has to do with using a custom Makefile for
>> development though.  You don't make a release distribution by tarring
>> together your development tree.
>
> And I don't see what packaging a release distribution has to do with  
> the problem Jordi mentioned: Namely that in a port, a supported engine  
> was "overlooked" and "forgotten", and we only noticed by chance that  
> the PS2 port didn't enable the Igor engine at all -- neither in its  
> development (trunk) version nor in its release version. This happened  
> because the port keeps a separate list of engines to en-/disable.

I'm just saying that having a separate make system does not affect
which engines are enabled in releases as long as you don't use that
separate system for building the releases but only for development.

If the porter fails to document which engines are en- or disabled
differently from the default when building a release with the
configure script, that is a separate problem.


>> Isn't it rather that it's difficult to know which engines are enabled
>> in a release build because it depends on the command line options
>> given to configure instead of something stored in a file (like a
>> Makefile for example :) ?
>
> Actually, no: The engines which will be enabled are also stored in a  
> file, just a different one (namely "configure" instead of a port  
> specific Makefile). The advantage of configure is that the very same  
> list is used in all ports, so that ports can no more accidentally  
> "forget" a supported engine. Nor accidentally enable one that they  
> shouldn't enable ;).

The list in the configure script is used by default, but you can
override it with command line options.  Which is what I said in the
text you quoted by the way...  If the engine is disabled by editing
(and committing) a makefile, this can be seen in the source
distribution.  Not so if it is disabled by running configure with a
command line option to disable it.

This should not be takes as an argument for building releases using
custom Makefiles, I'm just confused why difficulty to track custom
enablings/disables should be considered an argument _against_ it,
as it seems the other way around to me.


> If, however, a port author really really wants to enable only a very  
> specific list of engines (e.g. for the DS port, which currently still  
> needs several binaries with different engines en-/disabled), then this  
> can still be done, by doing
>    ./configure --disable-all-engines --enable-ENGINE1 --enable- 
> ENGINE2 ...

Exactly.  And then there is no trace anywhere that this has been done.


> Custom Makefiles based on our Makefile.common have another drawback:  
> Whenever we core devs want to enhance Makefile.common, we run the risk  
> of breaking some ports using custom Makefiles. OTOH, when a port uses  
> the configure based build system, the chance for breakage is much  
> smaller. Example: I recently added a new variable LD to configure,  
> which forced you to set LD in backends/platform/dc/Makefile (and I  
> would bet various other custom Makefiles are currently broken because  
> of it).
> This kind of pain would be gone ... :)

Well, since this is my "pain" which I choose myself, it shouldn't
really matter one way or the other to you or anyone else...

And besides, you can break ports by changing Makefile.common even if
there is no custom Makefile.  It's just something to deal with.


[...]
> OK, fair enough. Although, I wonder, aren't such changes usually of a  
> temporary, experimental nature? If so, couldn't they just as well be  
> made to config.mk? That's how I usually do these things when working  
> on the SDL/OSX port.

It's usually a bad idea to make non-trivial changes to auto-generated
files.


  // Marcus






More information about the Scummvm-devel mailing list