Frederik Eaton
If they conform to the cabal standard, providing configure, build, and install steps, then they are built exactly the same. Can you be more specific about your question?
What I meant is, if a 'make'-based build depends on a cabal package being installed in a temporary location, how do we communicate to the 'make'-based build what that temporary location is?
That is a good point... I actually wouldn't really expect people to mix Simple build systems with Make build systems, but it could happen. If so, all we'd need to specify for GHC is the location of the package configuration file, which I would prefer to keep abstract if possible. Maybe we'll see if this is actually a problem in practice. (snip)
I caution you, though, on spending too much time making plans and designs and not much time writing code; the problem is usually that we have plenty of ideas about what needs to get done and not enough coders. The code base is pretty manageable, so if you want to help out, just pick something you think needs to get done, or ask me what is most important and start working on it :) I usually ask for help on this list when something comes up.
I caution you on the opposite. Cabal is very format and protocol-heavy. I imagine that much of the work has gone into documentation and mindshare, in which case it becomes very important to keep people informed and working together. Suggesting that individuals need to contribute patches unilaterally before anything will happen seems counterproductive to me, at least when it comes to some of the larger parts.
I'd be happy to try the wiki idea. I haven't done something like this recently because I haven't identified such a need; if I had a wiki page, I think I'd be the only one who reads it and the only one who modifies it. That's the case with the TODO list, which is under version control, so theoretically anyone could modify it, but no one does. I usually avoid adding "process" until a need arises. If we were ever in a situation where we need more analysis than code, then I would spend more time writing documents and wikis (which we used to do much more; you'll find old pages of discussion on the wiki, but not many people besides me contributed; it was mostly copying and pasting from mailing lists). We spent a lot of time on discussion and documentation early on in the project (probably a year), and the original proposal was the product of that work. I think that at some point, we will want to commit to a "cabal version two" where we will go into an analysis phase again. I just don't think we're at that point yet. I still think we just need to get code out there for people to try and see what works, what doesn't, and what the needs are that we hadn't anticipated. Cabal is still a very young project, believe it or not, and we have spent a great deal of its lifetime writing documentation and having discussions. I hope you won't begrudge me a few more months of writing code ;)
On a meta-tangent, if we could be discussing things on a wiki, rather than a mailing list, then I think discussions could go a lot faster. (snip for instance)
I am willing to try doing more on the wiki, but in the spirit of wiki, I think you should just go ahead and start it :)
I've attached a patch.
Thanks. (snip)
In a way, the problem isn't "lack of support" but a different model of finding packages... It's not like a compiler extension that one system supports and one doesn't; this flag breaks abstraction between compilers in a way that --in-place does not. I haven't heard any use cases where --in-place won't work.
Well, we're talking about two different features here.
I'm talking about use cases, not features :)
I want to be able to specify an arbitrary location. You want to be able to specify the current working directory. Not the same thing, is it? I think it should be possible to specify an arbitrary location, at least for ghc.
Since this breaks abstraction, I would prefer to avoid this until I see a convincing use case. (snip)
6) I think it should be easy to use 'cabal' for development; however, when I am building a package with multiple executables, every 'build' seems to re-link each executable, regardless of whether it needs re-linking or not, which is quite slow.
I'm not sure why ghc --make re-links executables every time.
For libraries, I think we could use support from ghc to tell whether we need to re-link the library; ghc goes through and skips stuff that doesn't need to get built, and then we link everything in the library; if ghc could somehow let us know that nothing needed to get built, that would be very helpful; otherwise, someone has to write the logic to go through and check it all just like ghc does. This code should be out there somewhere.
Isn't there a way to get ghc to emit Makefile fragments which solves this problem? Not that solving it in ghc wouldn't be good as well.
Relying on Make isn't any good for us for the simple build infrastructure; it needs to be more portable than that.
Really? Surely every platform has some basic 'make' installed.
I don't think it's the case that every platform has make installed. Windows, for instance. In fact, one convincing argument for cabal is that it doesn't require make.
And just parsing out the rules can't be that hard.
Interpreting a makefile is probably pretty hard. I don't want to do it, personally. But the rules that ghc produces are probably a subset of the entire make language... still, I'd think that it would be far more productive to write a dependency analizer that doesn't rely on ghc than to write a makefile interpreter that does. Writing a dependency analyzer for haskell files would be a huge benefit to cabal. Chalk that up there with important things to do along with fixing up the test suite and such if you start the wiki page. peace, isaac