August 2008 - cabal-devel

patch applied (cabal): Document and refactor 'parsePackageDescription'.
by Duncan Coutts 06 Aug '08

06 Aug '08

Mon Aug 4 12:03:24 PDT 2008 Thomas Schilling <nominolo(a)googlemail.com> * Document and refactor 'parsePackageDescription'. Hopefully this makes this function more understandable and easier to modify. M ./Distribution/PackageDescription/Parse.hs -39 +86 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080804190324-7c5c6-59960c58…

1 0

[Hackage] #319: Warn if the source file for a module is ambigious.
by Hackage 05 Aug '08

05 Aug '08

#319: Warn if the source file for a module is ambigious. ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- For example if we are looking for a module `Foo` and there are files `Foo.hs` and `Foo.y` then we should use `Foo.y` as we do now, but we should warn about the presence of `Foo.hs` (and note the fact that we're ignoring it). Similarly if we find `Foo.x` and `Foo.y` then we should warn about the one we're not using. Or arguably that should be a straight error. There's an obvious order relation between `Foo.hs` and `Foo.y` but not between `Foo.x` and `Foo.y`. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/319> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

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

05 Aug '08

On Tue, 2008-08-05 at 22:11 +1000, Roman Leshchinskiy wrote: > On 05/08/2008, at 21:15, Duncan Coutts wrote: > > > 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? > > I think I'm observing a different behaviour. I don't think a Parser.hs > left over from a previous build would have affected the build with the > behaviour you describe. I suspect it might be different behaviour between the cabal build and the makefile that the ghc build system generates. I just tried it with a simple test case and with cabal build it works how I expected. For the makefiles I defer to Ian and Simon. > Out of idle curiousity, what happens if Cabal finds both Foo.y and > Foo.x? Is all this documented somewhere? I couldn't find anything in > the Cabal docs but maybe I just looked in the wrong place. That's essentially undefined. It'll depend on the order in which we check the .x and .y suffix rules. That's the kind of ambiguous case I was suggesting we should warn about. Duncan

1 0

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