This sounds very reasonable on the surface, but I don't understand the consequences of this proposal. What are these consequences? Will this break `make`? (It sounds like it won't, given that the change is to Hadrian.) Does this mean horrible things will happen if I use `make` and `hadrian` in the same tree? (I have never done this, other than with hadrian/ghci, which seems to have its own working directory.) Basically: for someone who uses the build system but does not work on it, how does this affect me? (Maybe not at all!)
I would explicitly like to endorse the direction of travel toward Hadrian and away from `make`. Richard > On Feb 10, 2021, at 8:05 AM, Moritz Angermann <moritz.angerm...@gmail.com> > wrote: > > 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 > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
