[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

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

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.

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? :)

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