Re: [MiNT] trunk-09082010 file structure / content

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

On Tue, 2010-08-10 at 10:03 +0200, Miro Kropacek wrote:
> > Well, think of what ones we need.
> >
> > mintara.prg
> > mintmil.prg
> > mint000.prg
> >
> > And that's it, so we have three to start with. Now, I'm sure people with
> > 060's won't want to run the mint000.prg build, so we'll end up with
> > mint060.prg too, and people with 040's will probably be the same.
> This is where our point of view differs -- 000 build is there only
> because of its restrictiveness (!) to memory and resources usage,
> nothing more. So yes, in case 000 eats roughly the same memory as 030,
> I would vote for kicking out 030+ build as well. Look at Linux builds
> in distributions -- you hardly find SMP vs non-SMP versions, I can't
> remember when I saw -i686 or similar in my Ubuntu repository. One
> build is always easier to build / maintain / release.
> 
> > So the 020 option really ends up being only one more.
> It's always being only one more :) But if you count it, +1 060, +1 020
> (for no reason), then +1 040 and +1 Milan (because we can't / don't
> want to get rid of them so short before release). So seriously, do we
> have any reason why to include (for the start) 020 and 060 builds?

I'm thinking of people with 020's, but why is it such a big deal to
include it ? You are advocating not to include it, but does it actually
make your life harder in anyway ?

> > Now, getting back to a "MiNT loader" in this area would be nice. We just
> > have MINT.PRG in the AUTO Folded and then...
> >
> > c:\mint\1-17-0\000\
> > c:\mint\1-17-0\020\
> > c:\mint\1-17-0\060\
> > c:\mint\1-17-0\v4e\
> Sure, I liked Peter's initiative when he started his xaloader /
> mintloader patch, it was amazing idea, too bad he didn't find a
> motivation to continue. I sort of told myself to look at it after 1.17
> release, it annoys me really bad, I often want to test stuff on Aranym
> and Falcon (030/060 -- especially when I screw up something in CT60
> ;-) in the same time. But as time passed, I'm more and more motivated
> to make the opposite, i.e. unify / merge as much as possible into one
> kernel.

Eh? You've told me in an earlier thread that you only wake up in RC
time. No kidding. Now you want to merge into one kernel.

> I know what you think, BUT -- my goal will be to make it intelligent,
> i.e. CPU independent. So, you want 060 build? Ok, no problem, just add
> CFLAGS += '-m68060'. ColdFire? CFLAGS += '-m5475'. The rest will be
> handled by runtime detection and if really necessary, by #ifdef's for
> current CPU flags when compiling. This applies for whole system, i.e.
> XDDs, XFSs etc -- exactly as you planned.

Right. No big deal and flexible for everyone. Isn't life about choice,
and not about restricting people.

> So if someone will be in irresistible temptation to have kernel &
> modules for each CPU available, he can make a build with simple "make
> CC='gcc -m680x0'". What do think, better? :)

Then you are asking users to start doing kernel builds. Mmmm. Might as
well get them compiling themes into XaAES as well, and heck, why don't
we get them building their own distro and tools to go with it.

Bzzzzt. Wrong idea.

Alan.