- cabal-devel - Haskell.org

[Hackage] #852: Not possible to #include "*_stub.h" from C code
by Hackage 31 May '11

31 May '11

#852: Not possible to #include "*_stub.h" from C code ----------------------------+----------------------------------------------- Reporter: dankna | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Cabal doesn't make it possible to #include "*_stub.h" files from C code, because those files have not yet been generated at the time that it wants to check for their existence, which is during "cabal configure". At first I was going to ask for advice because I didn't really see a solution, but now that I think about it, I think correct behavior is to omit the check for whether stub files exist and compile, but to check for the existence of files which /could/ generate them, which is to say, are Haskell files and match the module portion of the name. So I'll implement that. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/852> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #853: Building mixed-language programs with Apple's Objective-C garbage-collection feature is difficult
by Hackage 31 May '11

31 May '11

#853: Building mixed-language programs with Apple's Objective-C garbage- collection feature is difficult ----------------------------+----------------------------------------------- Reporter: dankna | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Ideally, there would be a single flag to set the ObjC garbage collection mode. The three possibilities are, semantically, disabled, optional, and mandatory; I was experimenting with the mandatory mode, but there will be related issues with the others. One might expect the following to work: ld-options: -fobjc-gc-only In fact this will compile successfully but the linked object will have very subtle heap corruption due to the lack of a write barrier (which is implemented by gcc by hooking all field accessors, transparently to the developer). Why yes, this /did/ take me a while to track down! It is necessary to also add: cc-options: -fobjc-gc-only But once this is added, it is impossible to link any Haskell objects in, because they do not contain the magic flag which tells the linker they are GC-aware. We therefore need: ghc-options: -optc-fobjc-gc-only (I think this might force compilation via C when it wouldn't otherwise be used, which is of course undesirable, but I haven't looked into it.) This is somewhat of an ugly situation, but fortuitously, it is simple to remedy - Cabal merely needs to understand what needs to be done and do it! I propose to put the new field in BuildInfo, as it applies to both libraries and executables; to call it "objc-gc:", and to give it the values "Disabled", "Optional", and "Mandatory". I expect to have a patch for this ready sometime tomorrow. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/853> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

patch applied (cabal-branches/cabal-1.10): "TAG GHC 7.0.2 release" and 2 others
by Ian Lynagh 29 May '11

29 May '11

Thu Mar 3 07:02:38 PST 2011 Ian Lynagh <igloo(a)earth.li> tagged GHC 7.0.2 release View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal-branches/cabal-1.10;a… Wed Mar 30 12:29:43 PDT 2011 Ian Lynagh <igloo(a)earth.li> tagged GHC 7.0.3 release View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal-branches/cabal-1.10;a… Sun May 29 05:31:11 PDT 2011 Ian Lynagh <igloo(a)earth.li> * Bump version 1.10.1.0 -> 1.10.2.0 M ./Cabal.cabal -1 +1 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal-branches/cabal-1.10;a…

1 0

Re: cabal user's guide comment
by Duncan Coutts 29 May '11

29 May '11

On Sat, 2011-05-28 at 10:55 -0400, Jake Penton wrote: > On 2011-05-17, at 7:09 PM, Duncan Coutts wrote: > > > On Sat, 2011-05-14 at 11:22 -0400, Jake Penton wrote: > >> Greetings. > >> > >> What is a package? > >> > >> The reason I ask this question is stated below. If I am posting to the > >> wrong list, let me know. Also, my tone by be slightly abrasive: I am > >> rather frustrated. If I have misread the Cabal user's guide, or am > >> otherwise have my head up my butt, feel free to let me know. Also if I > >> can help (which I doubt, as a beginner) tell me how. > > > > This is very timely. I'm currently rewriting the user guide. > > > Ok, great. Thanks for your work. > > I have been away for two weeks, and so have only just been able to follow up on the answers to my post > > > > > Here's my current introduction, let me know what you think: > > > > http://code.haskell.org/~duncan/cabal/user-guide/#introduction > > > > I took a look at it the link. > > I seem to be having some trouble communicating what is puzzling me. > Again, the fault may be my own. At my level of knowledge I am often > unable to discern what is part of haskell proper, what is just ghc (or > another implementation), and what is a Cabal convention. Right, and new users shouldn't need to already know exactly where these boundaries are. > I have only skimmed the haskell 98 and 2010 reports; I should probably > read them in detail to begin to sort this stuff out. I do not see > anything in these documents that specifies how compilation units are > organized, or whether the hierarchical module namespace in haskell > somehow relates to a directory hierarchy. This is probably > implementation dependent. Yeah, strictly speaking the Haskell spec does not require modules to exist in files, so it doesn't give any file name mapping. Of course all the common implementations follow the same convention. The Haskell spec of course isn't a tutorial. What I'm thinking of is adding a bit to the beginning of quickstart that links to a section with tips on how to organise the files in a project dir, and in that section we can explain the standard convention that Foo.Bar maps to Foo/Bar.hs or .lhs. http://code.haskell.org/~duncan/cabal/user-guide/developing-packages.html#q… Or perhaps it's best to link to one of the basic tutorials http://www.haskell.org/haskellwiki/Tutorials > In reply to my original post David Peixotto pointed to the ghc user's > guide, which states that "A package is a library of Haskell modules > known to the compiler". May I take it, then, that on my Mac a cabal > package is an static archive file, i.e. 'some-package.a'? I doubt it. > The term "library" is pretty overloaded, so this description seems too > vague to be helpful. The definition there is an abstract definition, and it is referring to ghc's notion of a compiled and registered package. The actual representation of a compiled & registered package is not interesting or useful. You want to know how to make a package, and specifically what the source layout for one of these should be. > In another reply Antoine Latter stated that "A cabal package is a set > of files along with a package description file (named *.cabal)". So he's referring to a Cabal package, which is the source representation, as opposed to the compiled & registered ghc package that David mentioned. I'll add something to the package concepts section to describe the distinction and the relationship between the two. It's basically just the source vs binary versions of the same thing. > Ok, but I assume that the collection of files that make up a cabal > package are meant to be organized some way or other. The information > on this may be in the Cabal user guide somewhere, but it does not jump > out at me. May I conclude that I can have one of the files on the > flash drive in my pocket, another on a web server somewhere, and a > third one in my home directory on my Mac, and that these can > constitute a Cabal package? In the beginning of my new quickstart section I say that all these files need to live under one common project root directory. http://code.haskell.org/~duncan/cabal/user-guide/developing-packages.html#q… > What I believe is missing in the Cabal user guide is something like > what appears in the documentation on java packages. I am not really a > java programmer - my reference to it is only to clarify my point. Take > a look at the third paragraph of this page: > http://java.sun.com/docs/books/jls/third_edition/html/packages.html. > The paragraph begins thusly: "A package can be stored in a file > system...." The document then provides internal links to describe how > the various files that make up a java package might be organized. The > information appears very early in the document, which I would like to > see in the Cabal user guide. Right, so in Java packages are really part of the language whereas we have bolted them on the side which means we've ended up documenting packages in isolation and assuming people already know how a simple multi-module program is organised as files. But of course that division isn't known or useful to new users. > Thanks again. If I am being dense, kindly be patient. I'll get there > eventually! No, it's useful to be reminded that we already know this stuff already but that the path to getting there is surprisingly unclear. Duncan

1 0

Re: [Hackage] #188: Support building Objective-C modules
by Hackage 29 May '11

29 May '11

#188: Support building Objective-C modules ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.2.0 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: 6.8.1 Platform: Linux | ----------------------------+----------------------------------------------- Comment(by dankna): Ah, yes, I see that that fix was committed to GHC just seven weeks ago - which is barely older than my copy of ghc HEAD built from a git checkout. With that fix in place, everything "just works" for me. I listed the files in c-sources: and they worked fine. So it's in the pipeline towards release! By the way, it's slightly spooky conversing with someone without a name - you should really register on Cabal's trac. :) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/188#comment:9> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #188: Support building Objective-C modules
by Hackage 28 May '11

28 May '11

#188: Support building Objective-C modules ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.2.0 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: 6.8.1 Platform: Linux | ----------------------------+----------------------------------------------- Comment(by guest): What version of GHC are you using? See here for a somewhat recent ticket and fix related to this issue: http://hackage.haskell.org/trac/ghc/ticket/5025 My understanding is that no released version of GHC supports this. I documented the things that I tried, without success, on that ticket. So if you have some way to do it without the fix in that ticket I would be interested to see your cabal file. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/188#comment:8> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #188: Support building Objective-C modules
by Hackage 28 May '11

28 May '11

#188: Support building Objective-C modules ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.2.0 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: 6.8.1 Platform: Linux | ----------------------------+----------------------------------------------- Changes (by dankna): * cc: dankna@… (added) Comment: This appears to have been working for an indeterminate amount of time - you can specify .m files in c-sources and Cabal will hand them off to GHC, which will take care of figuring out that GCC is the appropriate backend and firing it off. So this ticket should probably be closed? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/188#comment:7> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #583: create application bundles on demand
by Hackage 28 May '11

28 May '11

#583: create application bundles on demand ----------------------------+----------------------------------------------- Reporter: kowey | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: Mac OS | ----------------------------+----------------------------------------------- Comment(by dankna): See http://www.haskell.org/pipermail/cabal-devel/2011-May/007545.html -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/583#comment:2> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[cabal-devel] Support for .app bundles on Mac OS X
by Dan Knapp 28 May '11

28 May '11

This is to summarize a conversation I had with dcoutts on IRC, for everyone's benefit. On the Mac, both libraries and executables can be packaged in "bundles", which are special directory structures that are treated as files by the graphical file manager. We already have a ticket, #583, proposing that we automate the creation of these bundles; I've been working on it. At this point I have a working prototype (see link to darcs repository, below) that runs using the hooks, and am simply working on integrating it with Cabal "for real". I'm aware that my prototype will need some changes to be accepted; in particular, I rebelled against the directory and filepath packages and wrote my own filesystem-portability layer, mostly out of frustration with System.Directory's recursive-delete function, which currently traverses symbolic links (very dangerous!) since it doesn't know about them. That will have to be changed, and also my discussion with Duncan brought up some issues with the interface that will need reworking. Now, bundles. There are two cases, .framework bundles which are for dynamically-linked shared libraries, and .app bundles which are for executables. In the spirit of avoiding feature creep, for now I'm just supporting .app bundles, but with an eye towards supporting .framework ones later; I think that's most of what people want, anyhow. Incidentally, a bundle can include other bundles, which will be linked with it magically at runtime. This is (among Mac fans) a very nice thing to be able to do, as it simplifies dependency distribution no end. The existing package cabal-macosx pulls in fgl (functional graph library) and MissingH to do some graph-theoretical stuff to chase dependencies and automatically include them in the bundle. I note that it would actually be better to only include things explicitly requested, as there may be licensing implications, and take the simpler stance that if you want to include frameworks in your bundle you can, uh, implement that feature yourself. :) Now, what are the prerequisites of building a bundle? To what extent can it be done generically, without the package author providing Mac-specific information? Well, the major obstacle to that is the Info.plist file, which is XML in a schema defined by Apple that is basically an attribute/value tree. That file contains various metadata. For detailed documentation on what it holds, go to the developer.apple.com link below and scroll down to "The Information Property List File", but I'll summarize here. There's a ton of stuff - a reverse-DNS-name along the lines of com.dankna.niftyprogram which is used to identify the program; a filename pointing to an icon file within the bundle; copyright string; version string; what OS version is required; names of Objective-C classes and .nib files to be instantiated. There's a list of document types the application recognizes, including both what its role is with regard to each (editor/reader/whatever) and how they can be identified (file extension; legacy four-character code; UTI, such as public.text or com.dankna.niftyprogram.document). There's a list of UTIs the application exports, which is separate from the list of document types but used by it. There's also a list of UTIs it imports. Because there's so much information, and because Apple may extend the set of information included at any time, I believe what makes sense to store in the .cabal is a path to an Info.plist file to be included into the bundle. The other approach would be to map all this information onto fields to go directly into the .cabal, and then generate the Info.plist from that. I'm willing to do the work to come up with that mapping and parse it all out, if people feel I should. It would have a certain elegance to it, as it would keep all metadata in only one place. Since Windows and Linux don't use UTIs, basically none of the information would be applicable to them. One idea that came up was to provide tools to generate an initial Info.plist file for the user to edit further. I don't think this would be useful; Apple already provides such tools, and it's not really practical to develop for the Mac without actually having a Mac to test on. Now, what else goes into a bundle? So far we've covered the compiled code itself, and the Info.plist metadata. There's also the Resources directory (located at NiftyProgram.app/Contents/Resources/), which contains, in general, arbitrary files such as icons, sounds, graphics, and localized text. But /in particular/ it contains .nib files, which are a binary serialization of GUI objects (and often non-GUI objects as well), and which are compiled by Apple's "ibtool" command-line program from .xib files, which are XML, although far too verbose to edit by hand. After some discussion with Duncan, he has convinced me that the right thing to do is to list everything that belongs in the Resources directory in the data-files: field, but recognize .xibs by their extension and run ibtool on them instead of copying them directly. Now, I would like to take a moment to note at this point that there is absolutely, positively no way to run a Mac GUI program without a .app bundle, and if there were, it would be unsupported and prone to causing the window manager to crash. So it makes no sense whatsoever to try to run "in place" out of the source tree without copying things into a .app bundle. The implication is that it makes no sense to include nibs/xibs in the installed data, unless we are building a bundle. So what I plan to do is this: There will be an additional boolean, determined at configure-time, that tells us whether we're building a bundle or not. That boolean will be testable with if-blocks in the .cabal file, using the syntax "if bundle". When building in appropriate circumnstances (more on that in a sec), it will default to true; otherwise to false; in either case it will be settable with configure-time flags --*-bundle and --no-*-bundle, where * is the name of the executable section, or --bundles and --no-bundles to set it for all executable sections at once. There is a difficult balance here because on most platforms, the choice of data-dir: is made by the person who builds the package, which is usually a different person from the one who authors it in the first place. But when building a bundle, there is only one possible choice, so we straddle the author/builder line a bit. Now, how do we default it? Well, first off, if we're not on a Mac, default to false (no bundle). If we're on a Mac, /and/ the package description is such that if we used true as the value we would have a bundle-info: field in the Executable section we are considering at the moment, then default to true. Otherwise, default to false. The intent of this is that if the author has provided the information we require to build a bundle, we want to build it by default; otherwise, we don't. The bundle-info: field is the one mandatory field to build a bundle, so it's appropriate to discriminate based on it. I envision that an app which is meant to build /only/ as a bundle would look like this: Executable NiftyApp if bundle bundle-info: Mac/Info.plist main-is: Mac/main.m other-modules: FrontEnd.Mac.Utilities includes: Mac/AppDelegate.h c-sources: Mac/AppDelegate.m data-dir: Mac/Resources data-files: Application.icns, Document.icns, MainMenu.xib frameworks: Cocoa other-modules: Network.Jabber, Network.SASL build-depends: base >= 4.1 && < 5, bytestring >= 0.9.1.4 && < 1, utf8-string >= 0.3.6 && < 1, direct-sqlite >= 1.1 && < 2 Notice how this puts main-is: inside the conditional, so that the package description is invalid if the condition is false. This is how we express the "only as a bundle" constraint. In contrast, an app which can also build a command-line version would look like this: Executable NiftyApp if bundle bundle-info: Mac/Info.plist main-is: Mac/main.m includes: Mac/AppDelegate.h c-sources: Mac/AppDelegate.m data-dir: Mac/Resources data-files: Application.icns, Document.icns, MainMenu.xib frameworks: Cocoa else main-is: FrontEnd.Terminal.hs other-modules: Network.Jabber, Network.SASL build-depends: base >= 4.1 && < 5, bytestring >= 0.9.1.4 && < 1, utf8-string >= 0.3.6 && < 1, direct-sqlite >= 1.1 && < 2 This provides an alternate main-is: value for building without a bundle, so that it's valid both ways. Notice the placement of the frameworks: flag; in the first example, it's just for consistency, but in the second example it actually makes a difference (not one which would keep the program from running, but it's still good to only link against libraries we're actually using). Also, it will be an error for a bundle-info: field to be present when the bundle flag is false; that way, the approach I've used in these two examples is more discoverable, since putting in bundle-info: without a conditional will lead to a helpful message. So much for the proposal; on to implementation. I recommend looking at my code in the prototype (the cabal-app link, below, in particular the function buildApp at the bottom of App.hs, linked separately for your convenience) to see what the steps are. Briefly, we start by removing any stale copy of the bundle that's around; we can't in general know whether the app itself has written to its own contents since we created it, so we have to get rid of it completely to be sure we don't have metastability that would lead to inconsistent ability to build. Then we create the directory hierarchy; write out a tiny file .app/PkgInfo that has to be there but can be autogenerated; copy the info plist (not to be confused with PkgInfo) to .app/Contents/Info.plist; compile .xibs to .nibs with output going to .app/Contents/Resources/; and copy other data files to .app/Contents/Resources/. So a full directory tree might look like: NiftyApp.app/ NiftyApp.app/PkgInfo NiftyApp.app/Contents/ NiftyApp.app/Contents/Info.plist NiftyApp.app/Contents/MacOS/ NiftyApp.app/Contents/MacOS/NiftyApp NiftyApp.app/Contents/Resources/ NiftyApp.app/Contents/Resources/Application.icns NiftyApp.app/Contents/Resources/Document.icns NiftyApp.app/Contents/Resources/MainMenu.nib Duncan spoke of wanting to partition this into "some simple build system extensions (like knowing what to do with compiling .xib files) and then a separate deployment phase". He didn't mean deployment phase as in "cabal install" but rather something new happening within but towards the end of "cabal build". Even though that's how my prototype does it, I think that because of reusing --datadir and data-files:, in the real version a partition is only possible to a very limited extent: We can, and will, make the bundle flag imply that --datadir is set to go within the bundle rather than in /usr/local/share/ or wherever, but that's not sufficient, since installing data files when building as a bundle is part of the build phase and not the install phase (it's impossible to run the .app without copying the files into their final places within it, so we haven't really built at all unless we do that). Notice, by the way, that this whole setup conflates the author/builder distinction a bit. Normally (without bundles), the builder gets to pick install paths. Here, the author is picking them, and the builder only gets to choose whether to accept those choices (build as a bundle) or not (build as a non-bundle, if the author has supported that, which of course isn't possible for GUI apps). The reason this is an acceptable restriction is that the final .app bundle is relocatable simply by moving it to anywhere the user wants it, so although the builder is restricted in his initial choices, he has more freedom ultimately. So - that's what I'm working on. Since the prototype is already working, I expect to have the real thing working in a day or two, and then hopefully we can get it added. Exciting stuff! See: http://hackage.haskell.org/trac/hackage/ticket/583 http://dankna.com/software/darcs/cabal-app/ http://dankna.com/software/darcs/cabal-app/Distribution/App.hs http://developer.apple.com/library/mac/#documentation/CoreFoundation/Concep… -- Dan Knapp "An infallible method of conciliating a tiger is to allow oneself to be devoured." (Konrad Adenauer)

1 0

Re: [Hackage] #504: executables with a C main function
by Hackage 28 May '11

28 May '11

#504: executables with a C main function ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: Platform: | ------------------------------+--------------------------------------------- Comment(by dankna): I have submitted a patch for this with darcs send. My patch simply relaxes the restriction on the name of the file given to main-is: to also allow known C-language extensions. The ticket description suggested that -no-hs-main might be required in this situation, but that seems to no longer be the case. There might still be a problem when the entry point is WinMain() instead of main(); see GHC ticket #2459 (at http://hackage.haskell.org/trac/ghc/ticket/2459 ). I'm not really set up to test that case. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/504#comment:4> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0