Stop holding hadrian back with backwards compatibility

[Moritz Angermann]

Hi,

so we've finally run into a case where we need to bump the rts version.
This has a great ripple effect.  There is some implicit assumption that
rts-1.0 will always be true. Of course that was a lie, but a lie we lived
with for a long time.

Now, hadrian tries *really* hard to replicate some of the Make based build
systems idiosyncrasies, this includes creating versionless symlinks for the
rts. E.g. libHSrts<X> -> libHSrts-1.0<X>. There is a great deal of logic
just to achieve this, and of course it all crumbles now.

I'd therefore like to float and propose the idea that we agree to *not*
bother (too?) much with make based build systems backwards compatibility
and warts that grew over the years in the make based build system with
hadrian going forward.

Yes, I can probably fix this, and add even more code to this burning pile
of complexity, but why?  The next person will assume libHSrts does not need
to be versioned and continue with this mess.

Let's have Hadrian be a clean cut in some areas (it already is, it does
away with the horrible abomination that ghc-cabal is--which only serves the
purpose of translating cabal descriptions into make readable files), and
not be bogged down by backwards compatibility.

This is thus my call for voicing concern or the upkeep of legacy support,
or I'll take silence as the collective support of making hadrian *not* be
held back by backwards compatibility. (This would mean in this case, that
I'd just delete the backwards compat code instead of adding even more to
it).

I hope we all still want Hadrian to replace Make, if not and we want to
keep Make, why are we concerning ourselves with Hadrian in the first place.
If we are intending to ditch Make, let's not be held back by it.

Cheers,
 Moritz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210210/effc469d/attachment.html>