Albert Y. C. Lai | 26 Nov 00:09 2012
Picon

cabal configure && cabal build && cabal install

Among many programmers, and/or users who manually unpack source tarball 
before installing, this idiom is very common:

cabal configure
cabal build
cabal install

This idiom is an urban legend, i.e., a popular error.

"cabal install" re-does the "configure" and the "build" steps, among 
other things. That it has not caused trouble for you so far is only because:

1. "configure" has been idempotent, so far
2. the 2nd "build" has not caused duplicate work because ghc knows when 
not to re-compile

One day, you will run into a surprise, because you will add some flags 
to "configure", and then...

cabal configure --prefix=/nondefault --enable-shared
cabal build
cabal install

Whee! Your laborously entered flags are lost on deaf ears. You get the 
default prefix, and you get the default disable-shared. Why?

Because "cabal install" re-does the "configure" step, but this time, 
since you give no flags to "install", you give no flags to the 2nd 
"configure" either.

(Continue reading)

Brent Yorgey | 26 Nov 02:08 2012

Re: cabal configure && cabal build && cabal install

On Sun, Nov 25, 2012 at 06:09:26PM -0500, Albert Y. C. Lai wrote:
> 
> If you begin with "cabal configure", the correct idiom is:
> 
> cabal configure [flags]
> cabal build
> [cabal haddock, if you want]
> cabal copy
> cabal register

Even this does not do the same thing as 'cabal install', because it
does not download and install any dependencies (whereas 'cabal
install' does).

-Brent
Herbert Valerio Riedel | 26 Nov 10:21 2012
Picon

Re: cabal configure && cabal build && cabal install

Brent Yorgey <byorgey <at> seas.upenn.edu> writes:
> On Sun, Nov 25, 2012 at 06:09:26PM -0500, Albert Y. C. Lai wrote:

>> If you begin with "cabal configure", the correct idiom is:
>> 
>> cabal configure [flags]
>> cabal build
>> [cabal haddock, if you want]
>> cabal copy
>> cabal register
>
> Even this does not do the same thing as 'cabal install', because it
> does not download and install any dependencies (whereas 'cabal
> install' does).

...but if he prepended a 'cabal install --only-dependencies' to the
invocation sequence it would, wouldn't it?
Kim-Ee Yeoh | 26 Nov 10:34 2012

Re: cabal configure && cabal build && cabal install

Nice tip, Albert! Good to know! One question I have is, is (runghc Setup.lhs) equivalent to (cabal) in  


runghc Setup.lhs <$> [configure, build, install]

?

On Mon, Nov 26, 2012 at 8:08 AM, Brent Yorgey <byorgey <at> seas.upenn.edu> wrote:
> [cabal haddock, if you want]
> cabal copy
> cabal register

Even this does not do the same thing as 'cabal install', because it
does not download and install any dependencies (whereas 'cabal
install' does).

Brent, that's useful to know too, thanks!

Fwiw, I think Albert had the backdrop of classic GNU autoconf in mind, predating all that newfangled stuff of downloading (!) dependencies (!!).



-- Kim-Ee
 

-Brent

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Albert Y. C. Lai | 27 Nov 00:21 2012
Picon

Re: cabal configure && cabal build && cabal install

On 12-11-26 04:34 AM, Kim-Ee Yeoh wrote:
> Nice tip, Albert! Good to know! One question I have is, is (runghc
> Setup.lhs) equivalent to (cabal) in
>
> runghc Setup.lhs <$> [configure, build, install]
>
> ?

Setup defaults to --global --prefix=/usr/local
cabal defaults to --user --prefix=$HOME/.cabal

This confuses a lot of people.

FAQ #1: Why does "Setup copy" abort and say "no permission"?
Answer: because you haven't escalated privilege for writing to /usr/local

FAQ #2: Why does "sudo cabal install" register nothing in both the 
global database and my database?
Answer: because "--user" means not global, and "sudo" means the user is 
root, not you. Look under /root.

Lastly, there is no "Setup install". Use "copy" and "register".

> On Mon, Nov 26, 2012 at 8:08 AM, Brent Yorgey <byorgey <at> seas.upenn.edu
> <mailto:byorgey <at> seas.upenn.edu>> wrote:
>
>      > [cabal haddock, if you want]
>      > cabal copy
>      > cabal register
>
>     Even this does not do the same thing as 'cabal install', because it
>     does not download and install any dependencies (whereas 'cabal
>     install' does).
>
>
> Brent, that's useful to know too, thanks!
>
> Fwiw, I think Albert had the backdrop of classic GNU autoconf in mind,
> predating all that newfangled stuff of downloading (!) dependencies (!!).

This is ignorant of a common workflow.

"cabal configure" is used by a lot of programmers. Today. Why?

Because they use it on their own projects. They use cabal-install as a 
builder, not exactly an installer.

In fact, some of them do:

cabal configure
cabal build
cabal register --inplace

This has no "cabal install" correspondence.

So you ask, "but surely their own projects require some packages from 
hackage?"

Yes, surely. But those packages have already been installed in the past, 
once and for all. That is, when the project started, they already did 
"cabal install yesod".

This is not so old-school, is it?
kudah | 27 Nov 07:02 2012
Picon

Re: cabal configure && cabal build && cabal install

On Mon, 26 Nov 2012 18:21:33 -0500 "Albert Y. C. Lai" <trebla <at> vex.net>
wrote:

> Lastly, there is no "Setup install". Use "copy" and "register".

$ runghc Setup.hs --help
> This Setup program uses the Haskell Cabal Infrastructure.
> See http://www.haskell.org/cabal/ for more information.
> 
> Usage: Setup.hs COMMAND [FLAGS]
>    or: Setup.hs [GLOBAL FLAGS]
> 
> Global flags:
>  -h --help            Show this help text
>  -V --version         Print version information
>     --numeric-version Print just the version number
> 
> Commands:
>   configure     Prepare to build the package.
>   build         Make this package ready for installation.
>   install       Copy the files into the install locations. Run register.
>   copy          Copy the files into the install locations.
>   haddock       Generate Haddock HTML documentation.
>   clean         Clean up after a build.
>   sdist         Generate a source distribution file (.tar.gz).
>   hscolour      Generate HsColour colourised code, in HTML format.
>   register      Register this package with the compiler.
>   unregister    Unregister this package with the compiler.
>   test          Run the test suite, if any (configure with UserHooks).
>   bench         Run the benchmark, if any (configure with UserHooks).
>   help          Help about commands
> 
> For more information about a command use
>   Setup.hs COMMAND --help
> 
> Typical steps for installing Cabal packages:
>   Setup.hs configure
>   Setup.hs build
>   Setup.hs install

On Mon, 26 Nov 2012 18:21:33 -0500 "Albert Y. C. Lai" <trebla <at> vex.net>
wrote:

> cabal configure
> cabal build
> cabal register --inplace

(newer) cabal build registers inplace automatically.
Albert Y. C. Lai | 27 Nov 08:20 2012
Picon

Re: cabal configure && cabal build && cabal install

On 12-11-27 01:02 AM, kudah wrote:
> On Mon, 26 Nov 2012 18:21:33 -0500 "Albert Y. C. Lai" <trebla <at> vex.net>
> wrote:
>
>> Lastly, there is no "Setup install". Use "copy" and "register".
>
> $ runghc Setup.hs --help
[...]
>>    install       Copy the files into the install locations. Run register.
>>    copy          Copy the files into the install locations.

I stand corrected, thank you. But then to complete answering a previous 
question, "Setup install" does not configure, does not build, and is far 
from "cabal install".

> (newer) cabal build registers inplace automatically.

I see where you heard this, but it is a misrepresentation from cabal, 
and older cabal has always told a similar misrepresentation.

When "cabal build" succeeds, it always says:

(older) "registering <name>-<version>"
(newer) "In-place registering <name>-<version>"

That's what it says. But use ghc-pkg and other tests to verify that no 
registration whatsoever has happened.
kudah | 27 Nov 10:40 2012
Picon

Re: cabal configure && cabal build && cabal install

On Tue, 27 Nov 2012 02:20:35 -0500 "Albert Y. C. Lai" <trebla <at> vex.net>
wrote:

> When "cabal build" succeeds, it always says:
> 
> (older) "registering <name>-<version>"
> (newer) "In-place registering <name>-<version>"
> 
> That's what it says. But use ghc-pkg and other tests to verify that
> no registration whatsoever has happened.

It doesn't register in user package-db, it registers in it's own
dist/package.conf.inplace. If it didn't you wouldn't be able to build
an executable and a library in one package such that executable depends
on the library.
Albert Y. C. Lai | 28 Nov 05:11 2012
Picon

Re: cabal configure && cabal build && cabal install

On 12-11-27 04:40 AM, kudah wrote:
> On Tue, 27 Nov 2012 02:20:35 -0500 "Albert Y. C. Lai" <trebla <at> vex.net>
> wrote:
>
>> When "cabal build" succeeds, it always says:
>>
>> (older) "registering <name>-<version>"
>> (newer) "In-place registering <name>-<version>"
>>
>> That's what it says. But use ghc-pkg and other tests to verify that
>> no registration whatsoever has happened.
>
> It doesn't register in user package-db, it registers in it's own
> dist/package.conf.inplace. If it didn't you wouldn't be able to build
> an executable and a library in one package such that executable depends
> on the library.

That's fair. But it also means

cabal configure
cabal build

is not equivalent to

cabal configure
cabal build
cabal register --inplace

which was the context when you said "(newer) cabal build registers 
inplace automatically".
Aleksandar Dimitrov | 10 Dec 12:12 2012
Picon

Re: cabal configure && cabal build && cabal install

On Mon, Nov 26, 2012 at 06:21:33PM -0500, Albert Y. C. Lai wrote:
> "cabal configure" is used by a lot of programmers. Today. Why?
> 
> Because they use it on their own projects. They use cabal-install as
> a builder, not exactly an installer.

Don't most devs nowadays use sandboxing, a.k.a. cabal-dev? I know I do, I've found
cabal to be impossible to work with as a development tool without sandboxing. I
think there was effort to bring cabal-dev like functionality to standard cabal
in the next big release.

Ah yes, here:

http://hackage.haskell.org/trac/hackage/wiki/SandboxedBuildsAndIsolatedEnvironments

In general, I consider sandboxing really important, even without dependency
hell: I will sometimes want experimental and/or old versions of libraries to
depend on that I don't want installed globally.

Best,
Aleks
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Gmane