[Haskell-cafe] Compilers

[John Meacham]

On Fri, Nov 28, 2008 at 08:51:45PM -0800, Jason Dagit wrote:
> On Fri, Nov 28, 2008 at 7:30 PM, John Meacham <john at repetae.net> wrote:
> > It is important to me that jhc be as widely accessible at possible. The
> > number of machines './configure && make install' will work on outnumbers
> > those that cabal install will work on hundreds or thousands to
> > one. I am pleased to have anyone experiment with jhc in the first place, I
> > don't want to make things harder for my users. This alone would be
> > enough of a reason all other things being equal, but other things arn't
> > equal to boot.
> 
> The command './configure && make install' only works in Windows if the user
> bother to install some form of unix environment emulation like msys or
> cygwin.  I don't know if windows platform support matters to jhc, but if it
> does that's one reason to want to provide an alternative to the autotools
> build option.

This always seemed like a rather weak argument, first of all, it's not
all that tricky to make autotools builds work on windows. Also, Windows
users by far prefer binary distributions anyway. They are downloading
the msi's rather than the source code. People who are actively
developing a project generally have a more advanced toolchain anyway.
Not that an easier windows build isn't useful, but that slightly easier
windows build is outweighed by the much more complicated build system
dependencies that are paid everywhere.


> Your arguments make it sound as though providing an option for building with
> cabal is out of the question.  Since I'm not invovled with JHC or LHC in any
> way I don't know how you would answer this question: Would you consider a
> cabal based build inaddition to the autotools one?
> 
>  Personally, I look at it this way.  Both build systems have different
> advantages that the other cannot provide but they are not mutually
> exclusive.  Also, the effort to keep them both working for the respective
> groups of users is rather small in practice.
                                                
This is sort of like splitting the baby, I don't think the effort is
really that small. A build system is a fairly complicated piece of code,
and it is also one of the parts I want more than anything to 'just work'
and having to worry about two different systems would not be productive.
A dumbed down build that is the intersection of both systems would be
barely usable and a drain on development effort.


I never was opposed to a cabal 'target' for jhc. I have 'make dist'
'make dist-rpm' and hopefully 'make msi' soon, adding a 'make
dist-hackage' alongside is not a bad thing, however, it is if it
complicates the standard build or comes to dominate development effort
or can't be done without duplication of functionality.

Cabal is not entirely conducive to being used in this way at the moment,
but this can be improved on. Some of the issues arn't too hard and
perhaps are being worked on, like adding a 'hackage release' field, and
a separate 'hackage' and 'project' maintainer fields. Others are
trickier, like the requirement to conform to hackages version numbering
policy that might differ from the native one. workarounds are possible
of course. But again, this is work. Even if the code isn't that much, it
does place a support burden on me and other jhc developers, so it isn't
something I'd do on a whim and without a clean design that does not
introduce any cabal dependencies on the standard build or require
ongoing support that is more than minimal, in fact, the
only time cabal should be invoked is specifically the case of installing
via cabal-install. 



> > And before you respond, think about this. What if the ghc developers
> > were constantly bombarded with whining from the perl people that ghc
> > doesn't use MakeMaker.pm since ghc uses perl in the evil demangler? What
> > would your impression of the perl community be?
> 
> 
> I don't recall if I've expressed this publicly before or not, but I'm not
> fond of the language specific reimplementations of make.  I think it's silly
> that every language has 2-3 language specific build systems and package
> formats.  But, it's too late for me to stop Cabal from existing.  

I totally agree.


> Hackage is
> too useful to ignore.  Using it increases my productivity.  Tools that use
> the Cabal format save me time and give me cool features for free.  I can
> easily run haddock or module graphs for example.  So, in short, if the perl
> community had a compelling argument based on what GHC is missing out on,
> then I think it would be fine for them to bring that to the attention of GHC
> HQ.
> 
> Now, the next point.  I think you're getting carried away here.  This fork
> was created without you being aware of it.  That makes me think the author
> of the fork didn't bombard you with whining.  So, I think we need to keep
> some perspective on that.  It's natural that you should have a fair bit of
> emotional attachment to the JHC -- you'd be weird if you didn't -- but as
> I've said before, I don't think any of this is an attack on you or JHC.
> Rather I think it's a fondness for JHC plus a desire to try different
> things.

Yeah, I should say that this wasn't really directed at Lemmih and the
other lhc authors. There actually was some discussion between me and
him, a fork was mentioned, I did not know it was followed through on
though until I saw this thread. To reiterate, Lemmih has made some great
contributions to jhc, I fully support diversity in projects, so welcome
the new effort. As long as the codebases are still compatible I expect
patches to flow both directions.

However, the issues I raised with cabal are real ones that concern me.
Not just when it relates to jhc, but to the future of the language as a
whole. There have been a number of projects I have been involved with
where things did get as bad as I implied above. If the only reason for
the fork was cabal, then that is disapointing. But I don't think that is
entirely the case.

        John

-- 
John Meacham - ⑆repetae.net⑆john⑈