Version control systems

[Bulat Ziganshin-2]

Hello Simon,

Tuesday, August 12, 2008, 5:46:59 PM, you wrote:

> GHC needs "core libraries" without which it cannot be built.  It is
> obviously highly desirable that a developer can build GHC with just
> one VCS, which suggests that the core libraries should be in git too.
> But those same core libraries are used by nhc98 and Hugs (I think
> that's all), and the last thing we want to do is to impose new costs
> on other implementations.  Diversity in implementation is a Good Thing.

why not ask hugs/nhc maintainers to switch to git too?

it seems that darcs while being good solution for small/medium
programs, hardly may be used for ghc. so, probably it should be
divided to 2 parts: "large things" including compilers and corelibs
should go into git and "small things" including all the 3rd-party libs
should stay with darcs



--
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@...

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Thomas Schilling-2]

On 12 Aug 2008, at 15:46, Simon Peyton-Jones wrote:
>
> It's unclear exactly what to do about this.  The most plausible
> possibility is to keep the core libraries that are shared with other
> implementations in darcs as now, and mirror them in git for GHC
> developers.  That will impose pain on GHC developers to keep the git
> stuff in sync with the darcs master copies; but at least other
> developers would be unaffected.
>

FWIW, I started a wiki page that tries a direct comparison between  
Darcs and Git:

   http://hackage.haskell.org/trac/ghc/wiki/GitForDarcsUsers

Some mappings are simple, some are more complicated and will require  
adopting a different workflow.  I still recommend reading a tutorial,  
but this cheat sheet should be a good start if you don't want to  
spend much time to learn Git just yet.  Where no directly  
corresponding command exists or emulating it would be too messy, I  
try to hint towards other work flows.

I encourage everyone to add useful tips and examples both from users  
who already use Git and later on, once we have gathered more  
experience.  I believe that Git has some features which can improve  
our productivity and I'd like this page to also collect tips how to  
do so.

/ Thomas
--
Push the envelope.  Watch it bend.





_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Norman Ramsey]

 > > I see an increasing problem in that every community comes up with
 > > their own package system, instead of reusing existing frameworks.
 >
 > That's because there are no usable existing frameworks.

I couldn't agree more.  I have been working on this problem off and on
since 1993, and the situation now is even worse than it was then.
It's become a full-time job just to keep track of the frameworks.
(For example, I'm not as informed about Omake as I'd like to be.)

As someone who hangs out in a bunch of different language communities,
I see two needs driving unnecessary diversity in build/package systems:

  1. Language implementors see that they are serving multiple
     platforms (debian, red hat, bsd, windows, macos, ...), each of
     which has its own native packaging system, with its own way of
     expressing dependencies.  The bad idea: invent a new system which
     works across all these platforms but serves only one language.
     This path was the genesis of 'Lua rocks', for example.  And
     although I can't speak of Ruby and Java of my own knowledge, I
     suspect that Ruby gems and Java beans are similar.  I don't
     really understand Cabal, but to the degree that I do, Cabal fills
     a similar role for Haskell.

  2. The technique of 'smart recompilation', described in a 1986
     journal article by Walter Tichy (who also invented RCS), has
     (again to my knowledge) has been reinvented again and again for
     one language after another---it has *never* been packaged as a
     reusable framework.  I know of two valiant efforts: Clemm and
     Osterweil's "Odin" build tool and Blume and Appel's Compilation
     Manager.  But the Odin people never really had a
     programming-language background, and Geoff Clemm was the only one
     who could extend the system.  And the Compilation Manager, while
     really interesting, didn't make it obvious how to use with
     another compiler---in fact I'm not sure if the hooks to support
     smart recompilation were even exported.

I also see repeatedly that the distinction between the build system
and packaging system is blurry: both have to know about build targets,
dependencies, and so on.

At the time of the wonderful GHC Hackathon in Portland, where the GHC
API was first introduced to the public, I urged Simon PJ to consider
taking ghc --make and generalising it to support other languages.
I still think this would be a good project.

 > There are tools to convert Cabal packages to native packages for rpm,
 > deb, ebuild and arch. The Cabal format was designed to allow this
 > translation. This includes dependencies on C libs and external programs.

I think this is an essential property for any language-dependent
packaging system to be successful.  I think this is a very good path
for Haskell, even though Cabal is a work in progress.  What I like is
that it overcomes an impedance mismatch:

  * The developer of a Haskell package is presented with *one*
    packaging interface (Cabal), which will create a package native to
    any widely used platform.

  * The client of a Haskell package treats it like any other native
    package: rpm, apt-get, emerge, or InstallShield just
    *work*---Haskell programs are not marginalized.

Of course this model puts a heavy weight on the shoulders of the Cabal
team, but given the current state of play, I don't see how it is
possible to do better for developers and users.  It's certainly better
than the 'Lua rocks' model, which requires the end user to run both
the platform-native packaging system *and* the Lua rocks packaging
system.  Such an outcome for Haskell is to be avoided at all costs.



Norman
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Isaac Dupree]

Thomas Schilling wrote:
> I encourage everyone to add useful tips and examples both from users who
> already use Git and later on, once we have gathered more experience.  I
> believe that Git has some features which can improve our productivity
> and I'd like this page to also collect tips how to do so.

what about `darcs send --dry-run`?  It's not perfect, but I
use it in my old repos in conjunction with `darcs wh [-l]`
to find out what of value I'd lose by deleting an old
checkout.  (e.g., patches merged into HEAD aren't of value.
  But they still aren't of value even if they've been
amend-recorded, rewritten, or equivalent by simon/ian/etc.,
but Darcs can't tell this, unfortunately.)

-Isaac
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Sean Leather]

Norman Ramsey wrote:

At the time of the wonderful GHC Hackathon in Portland, where the GHC
API was first introduced to the public, I urged Simon PJ to consider
taking ghc --make and generalising it to support other languages.
I still think this would be a good project.

 

As well as supporting any mix of languages (and platforms, since it's often difficult to separate the two). I would love to see such a tool! As flexible as make if necessary, but as easy as doing nothing if possible.

Sean

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Matthias Kilian]

On Tue, Aug 12, 2008 at 11:59:37AM +0100, Simon Marlow wrote:

> >Well, at least the Makefile creation was a step (the first step?)
> >into the wrong direction, IMHO. I'll run a GHC build to get some
> >of those generated Makefiles and followup on cvs-ghc, but for a
> >starter, Cabal shouldn't know anything about implementation-specific
> >internal build systems; instead it should rely only on it's own
> >metadata.
>
> I'm not completely sure, but I think you may have misunderstood how
> Cabal's makefile generation currently works.  It has no specific knowledge
> of GHC's build system, and it does rely on its own metadata.

I mean the GHC-specific template used for building the Makefile
(Distribution/Simple/GHC/Makefile.in) and the function `makefile`
in Distribution/Simple/GHC.hs (this function even spills out some
some make rules in addition to what's in Makefile.in, which looks
very wrong to me).

Yes, it relies only on the Cabal metadata, but the output is a
Makefile only useful for building GHC.

It'd be better to be able to run

$ ./Setup mkmetadata -prefix foo-

which just produces some simple variable declarations like

        foo-impl-ghc-build-depends = rts
        foo-impl-ghc-exposed-modules = Data.Generics Data.Generics.Aliases ...
        ...
        foo-exposed-modules = Control.Applicative Control.Arrow ...
        ...
        foo-c-sources = cbits/PrelIOUtils.c cbits/WCsubst.c ...
        ...
        foo-windows-extra-libaries = wsock32 msvcrt kernel32 user32 shell32
        foo-extensions = CPP
        foo-ghc-options =  -package-name base
        foo-nhc98-options = -H4M -K3M

Basically, the .cabal file is just converted into some other format
that may be included by another Makefile. And since it's a really
simple output format, it could even be used by different implementations
of make(1) or even other build tools. The `foo-' prefix just shields
variables in the including Makefile.

Take this output, write it to some cabalmetadata.mk, and then use
a (GHC-specific) Makefile copied over into all library directories
that does an

    include cabalmetadata.mk
    ...
    GHC_OPTS += $(foo-ghc-options)
    EXPOSED_MODULES = $(foo-exposed-modules) $(foo-impl-ghc-exposed-modules)
    EXTRA_LIBS = $(foo-extra-libraries) $(foo-$(HostOS_CPP)-extra-libraries)

Thus, Cabal dumps the metadata, without knowing how it's used. All
the remaining stuff are some (implementation specific) Makefiles
relying on recursive variable expansion.

I'll implement this for GHC when I've a little bit more spare time
(in three or four weeks).

> (in my other
> message I'm suggesting moving the Makefile generation into GHC's build
> system so that it could be made specific to GHC, though).

Generated files should be as simple, primitive and portable as
possible.  Generating complete Makefiles make things more difficult.
And it doesn't matter wether they're generated by Cabal or by GHC's
build system. If you've to tweak the build system, you don't want
to tweak generators but just an existing Makefile.

> > Implementation-specific stuff (such as how to run the
> >compiler) should be supplied by the implementation, not by Cabal.
>
> This is what makes me unsure.  Implementation of what?

The Haskell compiler. Or, to be more exact, the Cabal library shipped
with the Haskell compiler (or some supplementary compiler-specific
library -- I didn't think much about this part yet).

However, my main concern is the usage of Cabal from within the GHC
build system, so please just forget this part ;-)

> Are you suggesting
> a redesign of Cabal, or just changing the way something works?

I don't think that a large redesign is necessary. It should just
try to be as implementation-agnostic as possible.

Ciao,
        Kili

--
do yourself a favor and let the le(4)s rot on the junkpile of history...
                -- Henning Brauer
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Matthias Kilian]

On Tue, Aug 12, 2008 at 10:29:03PM +0200, Matthias Kilian wrote:
> Basically, the .cabal file is just converted into some other format
> that may be included by another Makefile.

Oops! I again read your (SimonM's) proposal on changing Cabal and
the GHC build system in exactly this way. Sorry for the noise.

Ciao,
        Kili
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Manuel M T Chakravarty]

Simon Peyton-Jones:
> | It is worth pointing out that I *never* validate against ghc head  
> when
> | I commit to the core libraries.
>
> I think that's perfectly reasonable for the reasons you explain.

Sorry, but I think the only reason its halfway acceptable is that  
Malcolm didn't break the GHC build yet.  If he does, I'll be screaming  
as loudly as for anybody else.

What Malcolm is basically saying is that he doesn't contribute to the  
functionality of the boot libraries, he simply makes sure they compile  
with nhc98.  That's a valuable contribution, of course, but to be  
honest, I don't think its a valid reason for us to go to the trouble  
of having two vcs for ghc.

Manuel

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Manuel M T Chakravarty]

Ian Lynagh:

> On Tue, Aug 12, 2008 at 10:10:31AM +0100, Malcolm Wallace wrote:
>>
>> On 12 Aug 2008, at 01:35, Manuel M T Chakravarty wrote:
>>> Ah, good point!  Changing ghc to git means *all* developers of boot
>>> libraries need to use git *regardless* of what repo format the boot
>>> libraries are in.  After all, they need to validate against the
>>> current ghc head before pushing.
>>
>> It is worth pointing out that I *never* validate against ghc head  
>> when
>> I commit to the core libraries.
>
> Also, all of the people who send us patches don't need to validate  
> (and
> I suspect most of them don't), as we validate the patches before  
> pushing
> them.

Well, its up to you whether you want to validate for other people, but  
I don't think that is the right policy.  Everybody (including Malcolm)  
should validate.

If you contribute code to the linux kernel, comprehensive testing of  
the code is a requirement, too.  It's not as if it were a strange  
requirement of GHC as an open source project to ask people to test  
their code properly.  In fact, I even tell my first year students that  
they should test their code properly.  Maybe we should hand books to  
introductory software engineering out to potential ghc and library  
contributors.  (Sorry to get cynic, but I can't believe that we are  
even discussing that.)

Manuel

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Manuel M T Chakravarty]

Ian, I completely agree with you.  I love the darcs vcs model, too.  
However, we have three discussions here:

(1) Do we want darcs vcs model?

     Except Thomas Schilling, who seems to be dead set to get rid of  
darcs, everybody who voiced their opinion seems to be in favour of the  
darcs model.

(2) Is the current implementation of darcs up to a project the size of  
ghc?

     Due to problems in the past & performance regressions with  
darcs2, a serious number of (important) people believe that the  
current implementation is not good enough.

(3) If we change the vcs for the ghc repo, do we change the vcs for  
the boot libs, too.

     This is just an open-source project maintenance question.  It has  
nothing to do with which vcs is better.

     This is the only point I have been arguing: *if* GHC's repo  
changes, all boot lib repos must change, too.

Manuel

Ian Lynagh:

> On Sun, Aug 10, 2008 at 08:17:50PM -0400, Norman Ramsey wrote:
>>> On Sat, Aug 09, 2008 at 06:56:23PM -0400, Norman Ramsey wrote:
>>>>
>>> personally I would much prefer to see money spent on making darcs
>>> better, for reasons I won't repeat again.
>>
>> I missed them and wouldn't mind receiving a private note.
>
> OK, I'll send to the list so that I have somewhere convenient to point
> people if this comes up in the future:
>
> * A lot of darcs's functionality could be refactored into generally
>  usable Haskell libraries, e.g. LCS-finding, downloading-with-libcurl.
>
> * darcs was once a flagship Haskell application, supporting the idea
>  that Haskell can be used in the real world. That image has mostly
>  faded away now due to the problems it has, but I think we can get it
>  back if we can get a high quality darcs out there. That would be good
>  for the community's image.
>
> * darcs has (in my opinion, at least) a much simpler, more intuitive
>  interface than the other version control systems. I don't think I'm
>  alone here, as I think this is where a lot of the resistance against
>  moving to git is coming from.
>
> * I think darcs is the Obvious, Right way to do version control.
>  Phil Wadler (at least, I think it was him; and probably many others
>  too) has said that the lambda calculus is universal, in the sense  
> that
>  if we were to meet a sufficiently advanced alien culture, it is  
> almost
>  inconceivable that they would not have also discovered the lambda
>  calculus. Darcs-style patch theory, before conflicting patches are
>  introduced, falls into the same category in my opinion. (I'm not yet
>  sure if it can be extended to include some definition of conflictors
>  too). By contrast, the heuristics and multiple merge algorithms of
>  other systems feels very ad-hoc.
>
>
> Thanks
> Ian

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Iavor Diatchki]

Hello,

On Tue, Aug 12, 2008 at 5:49 PM, Manuel M T Chakravarty
<chak@...> wrote:
> Ian, I completely agree with you.  I love the darcs vcs model, too.
>  However, we have three discussions here:
>
> (1) Do we want darcs vcs model?
>
>    Except Thomas Schilling, who seems to be dead set to get rid of darcs,
> everybody who voiced their opinion seems to be in favour of the darcs model.

I also don't think that the darcs model has much to offer over git, in
fact I find that it lacks some useful features (not counting a
reliable implementation).  Examples include good support for
branching, and being able to easily determine the version of the
software that is in a repository (git uses a hash of the content to
identify the current state, so it is easy to check if we two
developers have the same version of the content).

By the way, git's UI is really not as bad as people seem to think.
For everyday development "git gui" works very well, and provides a
nice GUI that lets you see what you have modified, choose what you
want to record, and push/pull from other repos.

-Iavor
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Bulat Ziganshin-2]

Hello Manuel,

Wednesday, August 13, 2008, 4:39:25 AM, you wrote:

> Well, its up to you whether you want to validate for other people, but
> I don't think that is the right policy.  Everybody (including Malcolm)
> should validate.

as far as we have people validating patches for their platforms (Igloo
for GHC, Malcolm for nhc...) this reduces amount of time required to
support things working. ideal solutions are too expensive for real
world :)


--
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@...

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Manuel M T Chakravarty]

Simon Marlow:

> Manuel M T Chakravarty wrote:
>> To be honest, if you ask me, I'd go back to the old makefile based  
>> system and remove Cabal from everywhere except building of the  
>> library packages.
>
> I wouldn't object to dropping the use of Cabal for other tools in  
> the build tree; the reasons for using it elsewhere are certainly not  
> as compelling as for packages.
>
> Ian, I realise this means backing out a lot of the work you've been  
> doing recently, and it would mean that we'd lose a lot of time in  
> the runup to 6.10.1, but perhaps it's a step that we need to take to  
> get us back on the right track again?

I do realise that this would mean backing out a lot of Ian recent  
work, and that's why I haven't proposed going back to the old system  
before you explicitly asked.  However, I am increasingly getting the  
feeling that the move to Cabal was pre-mature, and the overall loss  
will be minimised by backing out now.

In a sense, it was an interesting experiment and it should still be  
useful to the development of Cabal.  In fact, I see no reason why the  
experiment cannot be continued on a branch.  Who knows, maybe Cabal is  
sufficiently mature in a year to make a switch worthwhile?  I just  
object to using the whole GHC developer community as guinea pigs.

Manuel

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Manuel M T Chakravarty]

Ian Lynagh:

> On Tue, Aug 12, 2008 at 10:20:14AM +1000, Manuel M T Chakravarty  
> wrote:
>>
>> To be honest, if you ask me, I'd go back to the old makefile based
>> system and remove Cabal from everywhere except building of the  
>> library
>> packages.
>>
>> Manuel
>>
>> PS: Just for some more collateral damage.  Did anybody check whether
>> the Mac OS installer support and the -unfortunately, only partially
>> working- support to compile for older OS X versions that I added to
>> the *makefiles* still works with the Cabal-based system?  I doubt it.
>> Took me quite a while to get all this going, and I am not very well
>> motivated to spend a lot of time to figure out how it might work with
>> Cabal.  IMHO using Cabal for anything but the libraries was a step
>> back for no good reason.
>
> Do you mean the "rebuilding the tools with stage2" stuff? If so,  
> that's
> an interesting example to pick, as that was the impetus behind  
> changing
> how the build system worked for all the non-libraries/ghc.

Rebuilding with stage1 was already needed to build GHC with a builtin  
readline.  In general, it is a bad idea to build distributed binaries  
of Haskell programs with the *bootstrap compiler*.  It must be done  
with the stage1 compiler.  (If you are unsure why, I'll happily  
elaborate.)

What I was mainly refer to is the building of GHC.framework with  
xcodebuild and the accompanying packing with packagemaker.  Building  
for older versions of Mac OS X requires the MACOSX_DEPLOYMENT_TARGET  
and related infrastructure.

> Those changes made the build non-idempotent: we would build something
> with the bootstrapping compiler, build some other stuff, then come  
> back,
> clean it, and build it again with the in-tree compiler. This was a
> little annoying at the best of times, as e.g. rerunning make at the  
> top
> level would needlessly rebuild some stuff.
>
> However, when my local changes meant that programs built by GHC
> segfaulted, it was especially irritating to find that after  
> (hopefully)
> fixing the bug I couldn't just run make in compiler/ or rts/, because
> ghc-pkg etc now just segfaulted!
>
> It was at that point that I half-reverted the changes, and later I
> reimplemented something similar using Cabal. Now we make, for example,
> ghc-pkg with the bootstrapping compiler in utils/ghc-pkg/dist-inplace,
> and then later on we make it with the stage1 compiler in
> utils/ghc-pkg/dist-install.

It's of course much cleaner to build inplace versions of everything  
with the bootstrap compiler and separate distributeable versions with  
stage1.  I think we briefly talked about that during the run up to  
6.8.3.

> To answer your actual question: No, not having OS X yet I haven't  
> tested
> it, but I did make an effort to keep it working. In mk/cabal-
> flags.mk we
> say:
>
> USE_STAGE_CONFIGURE_FLAGS = \
>    ...
>    $(addprefix --cc-option=,$(MACOSX_DEPLOYMENT_CC_OPTS)) \
>    $(addprefix --ld-option=,$(MACOSX_DEPLOYMENT_LD_OPTS))
>
> which will hopefully do the trick, and (IMO) in a much cleaner, more
> maintainable way than would have been possible with the old build
> system.

I appreciate that you tried to preserve it, but things like those  
usually don't work until explicitly tested and debugged.  I think this  
illustrates the issue I am having with the current process.  I don't  
think large changes that have not been properly tested should be  
committed to the head.  I appreciate that you cannot test everything  
for every patch and don't have all the platforms at hand.  That's why  
major rejigging of the build system should be done on a branch.  Then,  
you can ask other people to test it, once it is all working well for  
you.  Ripping the guts out of the head and leaving some of them on the  
floor just means everybody else is going to trip over them.

Manuel
 
 
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Manuel M T Chakravarty]

Simon Peyton-Jones:
> 2.  The version control system (VCS)
>
> GHC needs "core libraries" without which it cannot be built.  It is
> obviously highly desirable that a developer can build GHC with just
> one VCS, which suggests that the core libraries should be in git too.
> But those same core libraries are used by nhc98 and Hugs (I think
> that's all), and the last thing we want to do is to impose new costs
> on other implementations.

What are these costs?  I don't believe there are serious costs for  
those developers.  Malcolm told us that all he contributes to the core  
libraries is fixing them for nhc when they break.  He doesn't even  
validate, so I am sure he doesn't use branches or anything similar.  
The cost for him is to learn how to get, record & push with git.

AFAIK, the only person who works on Hugs is Ross.  He contributes to  
GHC, too, and hopefully validates his library patches before pushing.  
So, he'll have to learn to use git anyway.

> It's unclear exactly what to do about this.  The most plausible
> possibility is to keep the core libraries that are shared with other
> implementations in darcs as now, and mirror them in git for GHC
> developers.  That will impose pain on GHC developers to keep the git
> stuff in sync with the darcs master copies; but at least other
> developers would be unaffected.

Everybody who contributes to the boot/core libraries needs to validate  
their patches.  If the GHC version of the libraries is in git, then  
all library code needs to be validated against the git version of the  
libraries before it can enter the master repository.  I don't see how  
that makes anything easier for anybody.

As I said before, I believe there is exactly one sane solution: all  
boot libraries use the same vcs as ghc.

Manuel

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Johan Tibell-2]

On Wed, Aug 13, 2008 at 2:49 AM, Manuel M T Chakravarty
<chak@...> wrote:
> Ian, I completely agree with you.  I love the darcs vcs model, too.
>  However, we have three discussions here:
>
> (1) Do we want darcs vcs model?
>
>    Except Thomas Schilling, who seems to be dead set to get rid of darcs,
> everybody who voiced their opinion seems to be in favour of the darcs model.

I'm also in favor of the switch to Git. The Git model has proved to be
both more productive and more reliable. And the interface, as far as
I'm concerned, is *better*.

Cheers,

Johan
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Simon Peyton-Jones]

| FWIW, I started a wiki page that tries a direct comparison between
| Darcs and Git:
|
|    http://hackage.haskell.org/trac/ghc/wiki/GitForDarcsUsers

Very helpful thank you!

Simon

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Simon Marlow-7]

Manuel M T Chakravarty wrote:

> Everybody who contributes to the boot/core libraries needs to validate
> their patches.  If the GHC version of the libraries is in git, then all
> library code needs to be validated against the git version of the
> libraries before it can enter the master repository.  I don't see how
> that makes anything easier for anybody.
>
> As I said before, I believe there is exactly one sane solution: all boot
> libraries use the same vcs as ghc.

I don't think this completely sane :-)

It's not fair or reasonable for the GHC project to require everyone else
contributing to the core libraries to validate their changes against
GHC.  We need to be branching the shared repositories, so that we can
keep the GHC branches working and sync up with the shared repositories
as necessary.  Morally this is the right thing; technically its a lot
more difficult than not forking.

What would make it much easier is for both the original shared
repository and GHC's branch to be git repositories (or branches of the
same repo): git is really good at having two parallel lines of
development that sync occasionally.  Having one in darcs and one in git
would be painful, but doable.

So I suggest we propose moving all the core packages to git, and we
translate all those for which nobody objects to the change.  For the
others, we'll keep them in darcs and live with the pain.

Cheers,
        Simon
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Simon Marlow-7]

Norman Ramsey wrote:

> I also see repeatedly that the distinction between the build system
> and packaging system is blurry: both have to know about build targets,
> dependencies, and so on.
>
> At the time of the wonderful GHC Hackathon in Portland, where the GHC
> API was first introduced to the public, I urged Simon PJ to consider
> taking ghc --make and generalising it to support other languages.
> I still think this would be a good project.

I don't want to speak for those involved, but I believe this is what the
"make-like dependency framework for Cabal" SoC project is doing:

http://vezzosi.blogspot.com/2008/06/my-summer-of-code-project-dependency.html

Cheers,
        Simon

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Simon Marlow-7]

Matthias Kilian wrote:

> I mean the GHC-specific template used for building the Makefile
> (Distribution/Simple/GHC/Makefile.in) and the function `makefile`
> in Distribution/Simple/GHC.hs (this function even spills out some
> some make rules in addition to what's in Makefile.in, which looks
> very wrong to me).
>
> Yes, it relies only on the Cabal metadata, but the output is a
> Makefile only useful for building GHC.

Ok, this statement is plainly not true, since I can use 'cabal makefile'
to build any package outside of the GHC build tree.  So perhaps I've
misunderstood your point?

> It'd be better to be able to run
>
> $ ./Setup mkmetadata -prefix foo-
>
> which just produces some simple variable declarations like
>
> foo-impl-ghc-build-depends = rts
> foo-impl-ghc-exposed-modules = Data.Generics Data.Generics.Aliases ...
> ...
> foo-exposed-modules = Control.Applicative Control.Arrow ...
> ...
> foo-c-sources = cbits/PrelIOUtils.c cbits/WCsubst.c ...
> ...
> foo-windows-extra-libaries = wsock32 msvcrt kernel32 user32 shell32
> foo-extensions = CPP
> foo-ghc-options =  -package-name base
> foo-nhc98-options = -H4M -K3M

Yes, we could use this to implement GHC's build system.  It's somewhat
similar to the scheme I suggested in the other thread, but more generic.
  I'd be completely happy to do it this way if the functionality would
be useful to others outside GHC too.

Cheers,
        Simon

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users