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

Max Horn max at quendi.de
Mon Oct 19 11:49:57 CEST 2009


Am 14.10.2009 um 21:04 schrieb Marcus Comstedt:

>
> Jordi Vilalta <jvprat at jvprat.com> 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.


>
> 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 ;).

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 ...

This in turn can be put into a script file for convenience. Of course  
this way the drawback that the list of en-/disabled engines can become  
out of date remains; but at least the code duplication has been reduced.


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 ... :)



>
>
>> Another advantage of relying on the main build system is that it will
>> help users and other developers to build your ports.
>
> The main build system is there and will help others even if I don't
> personally rely on it for my development work.

Absolutely true. Since the DC port is relatively obscure (no offense,  
I just mean that there are not that many using it and probably even  
less trying to compile it by themselves, compared to say the WinCE  
port), this is maybe an acceptable state to live in.

But in general, having two different build systems going can cause all  
sorts of annoyance. A bug might only show up when using the one build  
system but not in the other. This makes Q&A needlessly harder.

But since I don't have to do Q&A for the Dreamcast port, I don't  
really mind that much, just wanted to point this out :). If it works  
for you, fine. We are certainly not going to remove custom Makefiles  
behind people's back ;).



> And about the simplicity of using a custom Makefile, I think it could
>> be enough to replace it by a very small script that calls configure
>> with your preferred options. After that you should have the same
>> experience.
>
> Well, I'm only speaking for myself here, but to me the "simplicity
> of a Makefile" does not mean storing a fixed set of "preferred
> options", but rather a vehicle for temporarily changing how things
> are built; like switching to a different version of a library or
> changing the compilation flags of a single file just to see what
> happens.

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.



Cheers,
Max








More information about the Scummvm-devel mailing list