added sources not used for configure

[kquick]

Trying to add a source and then run configure fails:

$ ls foo something $ cd foo $ cabal-dev add-source ../something $ cabal-dev configure Resolving dependencies... Configure foo-1.0... setup: At least the following dependencies are missing: something -any $

But if I skip the configure phase and jump to install, it seems to work:

$ cabal-dev install Resolving dependencies... Configuring something-1.3... Preprocessing library something-1.3... Preprocessing executables for something-1.3... Building something-1.3... ...

[creswick]

cabal-dev configure isn't well tested, I'm afraid. We very, very, rarely actually need to run cabal-dev configure, and instead just use cabal-dev install.

Unfortunately, many people run into this sort of problem (configure not working well, or at all); we need to figure something out, but I don't know what the best solution is.

Are there situations where you need configure? (I don't think I fully know if configure is necessary... I think it is, but I have a very hard time coming up with actual use cases that really do require configure.)

[kquick]

The problem I found with "cabal-dev install" is that it installs all the dependencies every time I run it.

I did seem to work around this a bit by manually "cabal-dev install DEP" all of the dependencies, which seemed to bypass a lot of the benefits of the cabal file... then I saw the "install-dependencies" command, so I haven't tried that but I'm guessing that would have been the Easy Way.

Perhaps just some documentation recommending the above would be helpful. I initially started using "cabal-dev" using the same methodology I used with cabal:

1. cabal configure
2. cabal build ...fix/change/add.. repeat step 2
3. cabal install

When working on my own projects, it isn't natural to think of "install" as the first step to take. Now that I know that cabal-dev install is (a) the natural step, and (b) installs into a local directory rather than system directories, it doesn't feel so unusual.

I guess (thinking out loud here) there's a couple of potential fixes:

1. Update the documentation to recommend/explain "cabal-dev install" and "cabal- dev install-dependencies".
2. Change the command set for cabal-dev to not try to mirror cabal and instead supply on the commands that are needed or make sense for cabal-dev. This is a little radical, but if "cabal-dev configure" tends not to work most of the time then don't build the path to that cliff edge.
3. Figure out why cabal configure doesn't work. I took a very brief look at the code and I'm guessing this won't be easy since it looks like most of the time cabal-dev just tries to pass-through with adding the local package set; therefore the malfunction is not a clear "oops" in cabal-dev code and may be due to some complex interaction with cabal itself.

Best Regards, -Kevin

P.S. There's a "cabal-dev ghci" command; what do you think of adding a "cabal- dev make" command. I started using cabal-dev on a project of mine that was in the very early stages and didn't have a .cabal file yet, so I was just building it with "ghc --make TGT". I spent a little bit of time and figured out how to add the arguments to that ghc line to reference the local package repository but it would have been convenient if "cabal-dev make [ARGS]" == "ghc --make {local-pkg-ref} [ARGS]". OTOH, I quickly took the easy way out and made a .cabal file, so really this just helps the "simple tinkering" folks who are writing blog demos or other early code that hasn't decided to become a project yet. Worth it, or just feature creep in cabal-dev?

Quoting creswick <reply +i-898954-5115d429279332bad66a89a3b6015e2ff32be941@reply.github.com>:

cabal-dev configure isn't well tested, I'm afraid. We very, very, rarely actually need to run cabal-dev configure, and instead just use cabal-dev install.

Unfortunately, many people run into this sort of problem (configure not working well, or at all); we need to figure something out, but I don't know what the best solution is.

Are there situations where you need configure? (I don't think I fully know if configure is necessary... I think it is, but I have a very hard time coming up with actual use cases that really do require configure.)

Reply to this email directly or view it on GitHub: https://github.com/creswick/cabal-dev/issues/19#comment_1218621

---

This mail sent through IMP: http://horde.org/imp/

[j3h]

@kquick: in my experience, the problems with cabal install unnecessarily rebuilding dependencies have gone away with recent versions of cabal and cabal install. I used to see that behavior frequently, but I have not seen it with:

$ cabal --version
cabal-install version 0.10.2
using version 1.10.1.0 of the Cabal library 

[j3h]

@kquick: I just took another look at this, and I think it would work fine if you had installed the dependency instead of used add-source. Using add-source is equivalent to putting something on hackage. cabal configure won't see things that are on hackage, only things that are installed. I think that this is probably a documentation bug, since it wasn't clear how add-source could be useful.

[kquick]

That's a bit unfortunate. Often during Haskell development I find that I
can break my project up into logical sub-modules. I create a cabal
package for each sub module, and then use add-source in the higher-level
module builds. If I don't do this, then I have to add the sub-modules to
my user packages, right? Which is what I was trying to avoid with
cabal-dev to start with. Maybe I misunderstand the use case for
add-source though...

-KQ

On Tue, 12 Jul 2011 16:59:18 -0700, j3h
[email protected]
wrote:

@kquick: I just took another look at this, and I think it would work
fine if you had installed the dependency instead of used add-source.
Using add-source is equivalent to putting something on hackage. cabal
configure won't see things that are on hackage, only things that are
installed. I think that this is probably a documentation bug, since it
wasn't clear how add-source could be useful.

[j3h]

You did describe the use case for cabal-dev, and add-source accurately. The only difference is that after using add-source, you need to use cabal-dev install instead of cabal-dev build in order to build against the added sources. Here's how I would use it:

$ cd myapp
$ cabal-dev add-source ../mylib # and any other deps that you want to sandbox
$  # Build this package, and build the dep if necessary (installed into the sandbox)
$ cabal-dev install

-- or --

$ cd myapp
$ cabal-dev add-source ../mylib # ...
$
$ # Install the deps. into the sandbox once. Repeat if you change the deps.
$ # If you have cabal-install older than 0.10, you need to use
$ # "cabal-dev install-deps" instead of "cabal-dev install --only-dependencies"
$ cabal-dev install --only-dependencies
$
$ # Build only this package, and do not install it into the sandbox.
$ cabal-dev build

-- or --

$ ls
mylib/ myapp/
$
$ # Resolve the dependencies of all named packages together,
$ # build them all, and install them into the sandbox. Note that this
$ # does not unnecessarily rebuild sources, although it does relink
$ # every time. This only works with cabal-install > 0.10, but it's
$ # fantastically easy, especially if you are making changes to both
$ # mylib/ and myapp/, or if you have a lot of source directories.
$
$ cabal-dev install mylib/ myapp/ # ...

Each of these workflows has benefits and drawbacks, but they all accomplish the goal of building a multi-package project in a sandbox separate from other builds. I suggest you try each of them out and see which one works best for you.

[kquick]

Good stuff (docs/wiki if not already there). I think another conceptual piece for newcomers is that you really don't want to use "build" with cabal-dev, but "install" instead, and that it will only install here as opposed to some system or user-wide location.

Hmm... is cabal-dev build even useful given these hidden surprises.

-KQ

P.S. Still loving cabal-dev... there's no going back to regular cabal for local project development!

Quoting j3h <reply +i-898954-5115d429279332bad66a89a3b6015e2ff32be941@reply.github.com>:

You did describe the use case for cabal-dev, and add-source accurately. The only difference is that after using add-source, you need to use cabal-dev install instead of cabal-dev build in order to build against the added sources. Here's how I would use it:

$ cd myapp
$ cabal-dev add-source ../mylib
$ cabal-dev install

-- or --

$ cd myapp
$ cabal-dev add-source ../mylib
$
$ # If you have cabal-install older than 0.10, you need to use
$ # "cabal-dev install-deps" instead of "cabal-dev install

--only-dependencies" $ cabal-dev install --only-dependencies $ cabal-dev build

-- or --

$ ls
mylib/ myapp/
$ # This only works with cabal-install > 0.10, but it's fantastically

easy, $ # especially if you are making changes to both mylib/ and myapp/. $ # The downside is that it can be quite slow since it resolves dependencies $ # and relinks each library every time its invoked. $ cabal-dev install mylib/ myapp/

Each of these workflows has benefits and drawbacks, but they all accomplish the goal of building a multi-package project in a sandbox separate from other builds. I suggest you try each of them out and see which one works best for you.

Reply to this email directly or view it on GitHub: https://github.com/creswick/cabal-dev/issues/19#issuecomment-1581425

---

This mail sent through IMP: http://horde.org/imp/