Re: [MiNT] Set of patches for current release

[Miro Kropacek <miro.kropacek@gmail.com>]

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

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.

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

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

-- 
MiKRO / Mystic Bytes
http://mikro.atari.org