Re: [MiNT] Still don't get it - difference between 68020 and 68020-60

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

On Sun, 2010-06-20 at 12:45 +0200, Vincent Rivière wrote:
> Alan Hourihane wrote:
> > Realistically we have....
> >
> > 68000 (Stock ST)
> > 68000+68881 (Mega STE with FPU)
> > 68020 (Stock ST with accelerator)
> > 68020+68881 (Stock ST with accelerator with FPU)
> > 68030 (Stock Falcon)
> > 68030+68882 (Stock TT)
> > 68040 (Afterburner / Hades 040)
> > 68060 (CT60 / Hades 060)
> >
> > I think we should have them in multilib, at least in the GCC compiler.
> 
> Do really all stock Falcon lack an FPU ?
> I understood some had one...

Doesn't matter. The fact is that some Falcon's shipped without, and
therefore the basic Falcon is without.

> Note for readers: the 68040 and 68060 have an integrated FPU, so it is 
> implicitly enabled by default.
> 
> For the multilib settings, your list has to be multiplied by 2 with -mshort 
> at least for libgcc and libgem to be able to build the FreeMiNT kernel.

Right, that's implicit in my list.

> The result is a very big list, there is very few problems with that:
> 
> 1) For the executables packages, this solution is perfect because the final 
> users have just to pickup the package optimized for their machine and they 
> get optimal results.

Right. Developers get the whole GCC package ready to go for whatever
target they want to build for, regardless of what package maintainers
want to do.

> 2) For the libraries binary packages: I really believe everyone should be 
> encouraged to build software for all the supported multilibs. So the -devel 
> packages should contain all the multilib variants, they may become huge. 
> This is the only issue.

We have large disks these days, I don't see a problem.

> 3) For the complexity of building the packages, this should be solved once 
> for all the packages. The source packages should not contain any multilib 
> settings. Ideally, the source package should be able to autodetect all the 
> multilibs supported by the compiler (like the libraries provided by GCC do) 
> and automatically build all the binary packages accordingly.

This is tricky, and I'm not sure what normal "configure" scripts do with
multilib. I suspect it may mean building the package multiple times to
get the required libraries rather than trying to fix the build to build
them in a single pass. Here I mean using "CFLAGS=-mshort -m68000" etc,
etc, etc. on each "configure" pass.

> 4) All the build system must be automatable and automated. A developer 
> should only have to post a source package to a build farm, then all the 
> binary packages would be automatically built. If there is no build farm, the 
> developer should only have to type a single command on his machine to build 
> everything.

See above, as I don't this this works as is, and multiple builds with
different CFLAGS will be necessary.

> 5) For a distribution like Gentoo, the multilib stuff could be totally 
> disabled (this is the default behaviour, isn't it ?), and everything would 
> be compiled only once, for the native system.

For Gentoo, I build GCC "with" multilib, but the rest of the system is
built only once for the required "CFLAGS,CXXFLAGS" so the entire system
is already optimized for the target CPU. It means for me, that I'll need
different Gentoo tarballs for each target. I don't see that as a
problem.

> Really, if we decide something, things will become very simple afterwards.

Sure. But the main part here is the GCC patch. We should be enabling
developers to do the maximum possibly with our platform. Once that's in
place, it's the package maintainers responsibility or developer to
choose on how they work.

If we can sort out the GCC part, the rest will follow :-)

Thanks Vincent!

Alan.

Alan.