[fpc-devel] Summer of code collaboration

[Marco van de Voort]

In our previous episode, Jonas Maebe said:
> >> I never spent more than an evening on the test though, since I rather get
> >> rid of all the mingw parts instead (think fpmake here)
> > 
> > This might be the best. Let's see that fpmake can handle all that and then get rid of the remaining tool dependencies.
> 
> As I've said before: I think the compiler and RTL should remain
> Makefile-based (whether or not that is in addition to fpmake support for
> them, doesn't matter to me), to make porting to new platforms easier. 

I spoke mainly for the release situation. Primarily I would want to get
rid/minimize of own distributions of toolchains on non *nix.  (3x windows,
go32v2 and OS/2).

> "make cycle" is a very nice and easy test, and it would be quite annoying
> if fpmkunit and all of it dependencies would have to be compilable/working
> and installed before that could be performed.  It would also make the
> bootstrapping process in general much more complex.

Does anything really get more compilated then compiler/Makefile ? :-)
(3800 lines, .fpc is 900 lines, but I bet there is quite some in the
template that is for compiler+rtl dirs only too)

I agree that one has to be very conservative, and probably keep makefiles
for rtl+compiler around a long, long time, and even longer as for *nix, but
that is something else then saying "forever".

I don't think it is wise to say either keep makefile forever OR force fpmake
long term for everything before the fpmake system is actually there, and
ripened, and cross/bootstrap scenarios covered. Currently there is nothing
to compare.