<div dir="ltr">I want to second Marcus's comments. I understand the benefits of a uniform make system, especially after this discussion, but there are some things custom makefiles are simply better suited for. <br><br>

A few more points to add to Marcus's:<br><br>- configure is bloated -- I already get several things I don't really want, like defined directories that are not relevant at all to my port inside <a href="http://config.mk">config.mk</a>.<br>

- With configure, the 'makefile' is spread out and hard to see/follow. You then have to follow the shell script logic to the resulting <a href="http://config.mk">config.mk</a>. You could say the same thing about makefile.common, but I don't think it's the same level -- this is at least 1 more level of indirection.<br>

- Running configure itself is slow (at least on my system). Not a problem when you have to do it once, but doing it every time I change something  gets annoying fast.<br><br>Yotam<br><br><br><br><div class="gmail_quote">
On Mon, Oct 19, 2009 at 11:26 PM, Marcus Comstedt <span dir="ltr"><<a href="mailto:marcus@mc.pp.se">marcus@mc.pp.se</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><br>
Max Horn <<a href="mailto:max@quendi.de">max@quendi.de</a>> writes:<br>
<br>
>> [...]<br>
>>> I guess there may be errors in the supported engines table, but for<br>
>>> example I think several ports are distributing the Igor engine<br>
>>> enabled<br>
>>> by default (which isn't stable yet), and the PS2 had several stable<br>
>>> engines disabled until a few hours ago.<br>
>><br>
>> I don't see what this has to do with using a custom Makefile for<br>
>> development though.  You don't make a release distribution by tarring<br>
>> together your development tree.<br>
><br>
> And I don't see what packaging a release distribution has to do with<br>
> the problem Jordi mentioned: Namely that in a port, a supported engine<br>
> was "overlooked" and "forgotten", and we only noticed by chance that<br>
> the PS2 port didn't enable the Igor engine at all -- neither in its<br>
> development (trunk) version nor in its release version. This happened<br>
> because the port keeps a separate list of engines to en-/disable.<br>
<br>
</div>I'm just saying that having a separate make system does not affect<br>
which engines are enabled in releases as long as you don't use that<br>
separate system for building the releases but only for development.<br>
<br>
If the porter fails to document which engines are en- or disabled<br>
differently from the default when building a release with the<br>
configure script, that is a separate problem.<br>
<div class="im"><br>
<br>
>> Isn't it rather that it's difficult to know which engines are enabled<br>
>> in a release build because it depends on the command line options<br>
>> given to configure instead of something stored in a file (like a<br>
>> Makefile for example :) ?<br>
><br>
> Actually, no: The engines which will be enabled are also stored in a<br>
> file, just a different one (namely "configure" instead of a port<br>
> specific Makefile). The advantage of configure is that the very same<br>
> list is used in all ports, so that ports can no more accidentally<br>
> "forget" a supported engine. Nor accidentally enable one that they<br>
> shouldn't enable ;).<br>
<br>
</div>The list in the configure script is used by default, but you can<br>
override it with command line options.  Which is what I said in the<br>
text you quoted by the way...  If the engine is disabled by editing<br>
(and committing) a makefile, this can be seen in the source<br>
distribution.  Not so if it is disabled by running configure with a<br>
command line option to disable it.<br>
<br>
This should not be takes as an argument for building releases using<br>
custom Makefiles, I'm just confused why difficulty to track custom<br>
enablings/disables should be considered an argument _against_ it,<br>
as it seems the other way around to me.<br>
<div class="im"><br>
<br>
> If, however, a port author really really wants to enable only a very<br>
> specific list of engines (e.g. for the DS port, which currently still<br>
> needs several binaries with different engines en-/disabled), then this<br>
> can still be done, by doing<br>
>    ./configure --disable-all-engines --enable-ENGINE1 --enable-<br>
> ENGINE2 ...<br>
<br>
</div>Exactly.  And then there is no trace anywhere that this has been done.<br>
<div class="im"><br>
<br>
> Custom Makefiles based on our Makefile.common have another drawback:<br>
> Whenever we core devs want to enhance Makefile.common, we run the risk<br>
> of breaking some ports using custom Makefiles. OTOH, when a port uses<br>
> the configure based build system, the chance for breakage is much<br>
> smaller. Example: I recently added a new variable LD to configure,<br>
> which forced you to set LD in backends/platform/dc/Makefile (and I<br>
> would bet various other custom Makefiles are currently broken because<br>
> of it).<br>
> This kind of pain would be gone ... :)<br>
<br>
</div>Well, since this is my "pain" which I choose myself, it shouldn't<br>
really matter one way or the other to you or anyone else...<br>
<br>
And besides, you can break ports by changing Makefile.common even if<br>
there is no custom Makefile.  It's just something to deal with.<br>
<br>
<br>
[...]<br>
<div class="im">> OK, fair enough. Although, I wonder, aren't such changes usually of a<br>
> temporary, experimental nature? If so, couldn't they just as well be<br>
> made to <a href="http://config.mk" target="_blank">config.mk</a>? That's how I usually do these things when working<br>
> on the SDL/OSX port.<br>
<br>
</div>It's usually a bad idea to make non-trivial changes to auto-generated<br>
files.<br>
<font color="#888888"><br>
<br>
  // Marcus<br>
</font><div><div></div><div class="h5"><br>
<br>
<br>
------------------------------------------------------------------------------<br>
Come build with us! The BlackBerry(R) Developer Conference in SF, CA<br>
is the only developer event you need to attend this year. Jumpstart your<br>
developing skills, take BlackBerry mobile applications to market and stay<br>
ahead of the curve. Join us from November 9 - 12, 2009. Register now!<br>
<a href="http://p.sf.net/sfu/devconference" target="_blank">http://p.sf.net/sfu/devconference</a><br>
_______________________________________________<br>
Scummvm-devel mailing list<br>
<a href="mailto:Scummvm-devel@lists.sourceforge.net">Scummvm-devel@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/scummvm-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/scummvm-devel</a><br>
</div></div></blockquote></div><br></div>