Re: [MiNT] Set of patches for current release

[Alan Hourihane <alanh@fairlite.co.uk>]

On Sun, 2010-08-15 at 11:47 +0200, Miro Kropacek wrote:
> > You've placed all the copying and hardcoding of filenames into the
> > Makefile, yet these should be split over the entire Makefile process.
> I had couple of reasons why not to do it:
> 
> 1. It was much faster to put on one place -- now if we agree this or
> that should / shouldn't be there, I just change one line, I don't need
> to edit each Makefile. I'm not sure how much time there is before
> release, so I thought it's better to check actual result (if people
> like it / find it useful) and not how it's done. This can be always
> changed later, esp. when you said something about changing whole build
> chain in a near future.

There's no point in doing it in the Makefile then, we might as well just
make a script which I already have. So no, sorry I don't agree with what
you have.

> 2. It's not always so easy, many outputs doesn't use TARGET (freemint
> kernels, xaaes kernels, most of XIF modules, ...) as you could see in
> my strip patch -- some hack (*.xif etc) is needed anyway.

No hacks are needed from what I can see. We just need to update
Makefiles accordingly.

> 3. Many files doesn't use TARGETs at all, like images, resources, ...
> so you have to specify them manually anyway.

Then update the Makefiles.

> 4. I'm not really sure if this is so bad -- you (or someone else)
> decides what to put into release -- so in case you insist of having
> ext2.xfs in release tarball, compilation must be successful in all
> cases. That's the reason why 'release' depends on 'all' and 'strip'
> targets. Only advantage in your approach is that output filename (if I
> change TARGET from ex2.xfs to ext2fs.xfs for example) but see point
> 2.) and 3.)
> 
> > Can you re-work it ?
> I'm afraid I'm out of time, I wanted to finish it this week (major
> parts of it at least) ... is it really that bad? I mean, it's for
> users, even if I code it in visual basic, if resulting file structure
> is good, who cares? If you really, really don't like it, we can split
> it into "Makefile.release" and run on your buildbot with make -f
> Makefile.release if you want :) Reworking of all Makefiles and even
> parts of build chain doesn't seem like a good idea merely days before
> release ...

I certainly don't want to modify Makefiles like this. You might as well
shift the entire diff to a separate shell script instead and we can
commit a new file.

Alan.