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

[yotam barnoy]

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.

A few more points to add to Marcus's:

- 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
config.mk.
- With configure, the 'makefile' is spread out and hard to see/follow. You
then have to follow the shell script logic to the resulting config.mk. 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.
- 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.

Yotam



On Mon, Oct 19, 2009 at 11:26 PM, Marcus Comstedt <marcus at mc.pp.se> wrote:

>
> 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
>
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20091021/22b86973/attachment.html>