- cabal-devel - Haskell.org

Re: head aches in parser/Parser.hs
by Duncan Coutts 05 Aug '08

05 Aug '08

On Tue, 2008-08-05 at 14:51 +1000, Roman Leshchinskiy wrote: > On 05/08/2008, at 14:15, Judah Jacobson wrote: > > > It seems that the old, pre-Cabal build system did not clean some or > > all of the preprocessed files (such as Parser.hs). This was not much > > of a problem in practice, because the Makefiles used the relative > > timestamps to tell whether to regenerate Parser.hs from Parser.y. In > > contrast, Cabal stores all generated files in a separate directory > > (compiler/dist-stage[1/2]), and thus doesn't need to look at relative > > timestamps; so it gets confused by the old, leftover Parser.hs et al. > > Ah, thanks for clarifying this. I did remove all the files by hand > eventually but couldn't figure out why this was necessary. > > > Ironically this is another reason that switching to Cabal is a win -- > > cleaning of preprocessed files happens automatically. > > Can't resist the urge to nitpick... IIUC, where the make-based system > would generate Parser.hs at most once per build Cabal now > (unnecessarily) regenerates it for each stage. So it is really using a > different algorithm with slightly worse performance but better > cleaning behaviour. It would have been trivial to implement with make, > too. > > But this has highlighted what is IMO a problem in Cabal's design. It > doesn't know that to generate the module Parser it needs to start with > Parser.y and just uses whatever source file it finds. It knows it needs to find a source file for the module Parser, so it looks for the ultimate source file that could generate it, which is the .y file. If there is any .hs file too then it's ignored (though arguably we should warn if we find a .hs file too). > If that happens to be Parser.y things work but if it finds something > else things break. It knows that .y can be pre-processed to .hs so if it finds both .hs and .y then it knows that .y is the ultimate source file and pre-processes that. Do you think this is the wrong behaviour or are you observing different behaviour? > This looks very fragile to me. Could Cabal perhaps allow .cabal > files to explicitly specify which source files to use? As in: > > exposed-modules: Parser(Parser.y) I don't think that's necessary. We can find the correct source file without hints. Though as I mentioned, it's arguable that we should warn if there is any potential ambiguity or search path shadowing. Duncan

1 0

Re: head aches in parser/Parser.hs
by Thomas Schilling 05 Aug '08

05 Aug '08

How is that better than having only the actual source files in you src directory? All generated files will go into dist-*/ and there's no way to confuse anything. Cabal does allow including pre-generated files in dist tarballs, but for development, generated files have intentionally be moved into dist/. On 5 Aug 2008, at 06:51, Roman Leshchinskiy wrote: > > On 05/08/2008, at 14:15, Judah Jacobson wrote: > >> It seems that the old, pre-Cabal build system did not clean some or >> all of the preprocessed files (such as Parser.hs). This was not much >> of a problem in practice, because the Makefiles used the relative >> timestamps to tell whether to regenerate Parser.hs from Parser.y. In >> contrast, Cabal stores all generated files in a separate directory >> (compiler/dist-stage[1/2]), and thus doesn't need to look at relative >> timestamps; so it gets confused by the old, leftover Parser.hs et al. > > Ah, thanks for clarifying this. I did remove all the files by hand > eventually but couldn't figure out why this was necessary. > >> Ironically this is another reason that switching to Cabal is a win -- >> cleaning of preprocessed files happens automatically. > > Can't resist the urge to nitpick... IIUC, where the make-based > system would generate Parser.hs at most once per build Cabal now > (unnecessarily) regenerates it for each stage. So it is really > using a different algorithm with slightly worse performance but > better cleaning behaviour. It would have been trivial to implement > with make, too. > > But this has highlighted what is IMO a problem in Cabal's design. > It doesn't know that to generate the module Parser it needs to > start with Parser.y and just uses whatever source file it finds. If > that happens to be Parser.y things work but if it finds something > else things break. This looks very fragile to me. Could Cabal > perhaps allow .cabal files to explicitly specify which source files > to use? As in: > > exposed-modules: Parser(Parser.y) > > Roman > > > _______________________________________________ > Cvs-ghc mailing list > Cvs-ghc(a)haskell.org > http://www.haskell.org/mailman/listinfo/cvs-ghc / Thomas -- Push the envelope. Watch it bend.

1 0

Re: Where should cabal install to by default?
by Duncan Coutts 04 Aug '08

04 Aug '08

On Mon, 2008-08-04 at 11:56 +1000, Manuel M T Chakravarty wrote: > Just some random remarks: Thanks for the useful feedback on OSX conventions. I was unaware about several of them. > * Hiding installed files in a . directory is very bad style IMHO. I > think that should never happen. Just on OSX or on Unix too? On Linux I'm not sure where else we could put things that's per-user. People seem to object strenuously to programs automatically putting files in any dir other than ~/.progname (or one or two other .files established by specification or convention). > Independent of whether you install right into /usr/local/bin or > whether you symlink or whatever. You might install files > under /usr/local/lib/cabal and then symlink, but probably its nicer to > installto /usr/local/lib/<package>-<version> and then symlink. For global installs we use prefx=/usr/local at the moment, so that mean /usr/local/lib/<package>-<version> for libs and /usr/local/bin for binaries. I've just implemented the symlinking feature so we could change the default on global installs to use the version suffix on binaries and symlink back into /usr/local/bin. Or do you mean we should install binaries into /usr/local/lib(exec?)/<package>-<version> and then symlink into /usr/local/bin. That would also be reasonable I suppose, though then the versioned binaries are not on the path. > * On OS X, its not generally appropriate to install into /usr/local > either. Each user has ~/Applications and ~/Library directories that > are usually used for per-user installs. Just generally using sudo and > put binaries into /usr/local is also bad because not every user will > have admin rights on the machine. Oh, great. I didn't know OS X had a standard location for per-user installs. That's excellent. So is there a preferred layout for those dirs? I'm guessing there probably is. > * ~/.cabal is bad on Mac OS, too. Preferences ought to go into ~/ > Library/Preferences/ Ok. BTW, in that case we should probably fix System.Directory.getAppUserDataDirectory to follow the system convention on OSX. Currently it uses $HOME/.appname on all unix systems (and the Windows convention on Windows). If necessary we may want to split getAppUserDataDirectory into a variant for config and another for data. Since cabal-install is a program should it still be using ~/Library/Preferences/ or is there are corresponding ~/Applications/Preferences/ ? Where would be appropriate for cabal-install put its download cache and build logs? > * Versioning should be the default (and not optional). Well, it's always configurable (distros that allow only a single version of a program probably would not want it for example), but yes, I think it's a pretty sensible default configuration. We version libs of course, but up 'til now all binaries have been unversioned. We recently added support for arbitrary program prefixes and suffixes (which can include program $version var) and adding unversioned symlinks into some other dir. It's less clear what we'd do on windows if we want versioned binaries since there are no links. Duncan

2 1

darcs patch: Document and refactor 'parsePackageDescription'.
by Thomas Schilling 04 Aug '08

04 Aug '08

Mon Aug 4 21:03:24 CEST 2008 Thomas Schilling <nominolo(a)googlemail.com> * Document and refactor 'parsePackageDescription'. Hopefully this makes this function more understandable and easier to modify.

1 0

patch applied (cabal-branches/cabal-1.4): Adjust registration to allow packages with no modules or objects
by Duncan Coutts 04 Aug '08

04 Aug '08

Mon Aug 4 08:58:26 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Adjust registration to allow packages with no modules or objects So ghc-pkg does not complain about missing files and dirs. M ./Distribution/Simple/Register.hs -3 +9 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/2008080415…

1 0

patch applied (cabal): Adjust registration to allow packages with no modules or objects
by Duncan Coutts 04 Aug '08

04 Aug '08

Mon Aug 4 08:58:26 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Adjust registration to allow packages with no modules or objects So ghc-pkg does not complain about missing files and dirs. M ./Distribution/Simple/Register.hs -3 +9 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080804155826-adfee-f10d1dbf…

1 0

patch applied (cabal): Don't try to install libHSfoo.a if the lib had no object files
by Duncan Coutts 04 Aug '08

04 Aug '08

Mon Aug 4 07:38:17 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Don't try to install libHSfoo.a if the lib had no object files To allow meta-packages. M ./Distribution/Simple/GHC.hs -5 +7 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080804143817-adfee-c696e269…

1 0

patch applied (cabal-branches/cabal-1.4): Don't try to install libHSfoo.a if the lib had no object files
by Duncan Coutts 04 Aug '08

04 Aug '08

Mon Aug 4 08:14:42 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Don't try to install libHSfoo.a if the lib had no object files To allow meta-packages. (Backport of equivalent patch in Cabal HEAD) M ./Distribution/Simple/GHC.hs -5 +7 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/2008080415…

1 0

Re: Where should cabal install to by default?
by Justin Bogner 04 Aug '08

04 Aug '08

Roman Leshchinskiy wrote: > On 04/08/2008, at 06:19, Duncan Coutts wrote: > >> And many new users don't know what a path is or how to change one. >> >> I'd like to avoid new users seeing: >> >> $ cabal install xmonad >> cabal: this didn't do what you expected, to fix it change the foo >> setting in your bar file. >> >> It's not friendly. >> >> Actually at the moment it's worse though: >> $ cabal install xmonad >> [.. lots of build output .. ] >> $ xmonad >> bash: xmonad: command not found >> # user gives up, assuming cabal is borked > > I don't think it's realistic to expect that things will magically work > for people who don't know what they are doing. In fact, I can't imagine > that there are a lot of people who would use cabal-install and not know > about paths. IMO, the goal should rather be to make installation simple > for those who do know what they are doing and also to prevent users from > shooting themselves in the foot as much as possible. > > That said, I would prefer installs to be global by default and to go > into the same directory/tree in which cabal-install itself lives. Also, > I don't think cabal-install itself should somehow invoke sudo. IMO, > local installs shouldn't have a default location; rather, the user would > be required to specify one in the prefs file or when invoking > cabal-install. > > Roman I agree with Roman. Programs should not invoke sudo for users (If I need root access, I want to ask for it), and the default should be global rather than guessing a local path. With these two together you get a much deserved permission error if you simply run the program without configuring it or explicitly using root, which is the same as most other install tools and very sane, in my opinion. _____ Justin Bogner

1 0

Where should cabal install to by default?
by Duncan Coutts 03 Aug '08

03 Aug '08

Hi folks, cabal-install is supposed to make things simpler for users, especially new users. It's partly successful at that currently. Many users do not know ghc-pkg even exists for example (not that it was a design goal but it seems to be a consequence). On the other hand we're currently failing users by not making programs they install work by default. Currently cabal-install installs all binaries to ~/.cabal/bin by default. It does per-user installs by default and uses ~/.cabal as its prefix. Obviously ~/.cabal/bin is not on the $PATH, so users who install say, yi or whatever find that typing yi at the prompt does not do anything even though they just installed it. That's a failure on our part. It should work, and if we cannot make it work by default then we need to tell users what they need to do to make it work. So I'd like to discuss what defaults we should use. For reference, these are the features that are implemented right now that we have to play with: * We can do per-user or global installs (affects which package db we use but it also changes the default prefix) * We can set any --prefix we like * We can use versioned binaries (ie adding -$version suffixes) * We can add symlinks to binaries in some other directory * We can use a commend like sudo to do the install phase We can control all these features in the ~/.cabal/config file. When cabal-install is first run it creates a default ~/.cabal/config file. So the question is what default it should set and how we report failure cases to the user. We do not have to use the same defaults on every platform. If we can get away with it I think it's much nicer not to make it interactive. Here's a couple suggestions: For unix systems, do per-user installs to --prefix=~/.cabal but if ~/bin exists then add symlinks there. Or perhaps if ~/bin is not a convention on that unix platform (eg OSX) then do global installs by default to /usr/local and use sudo for the install phase (we know that OS X comes with sudo where as it may or may not on other unix systems). Duncan

2 2