[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