[Hackage] #815: Feature Request: Translate buildplan to makefile
#815: Feature Request: Translate buildplan to makefile ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.6 Severity: normal | Keywords: makefile, make Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- For the following reasons, I would sometimes like to be able to use GNU make as my build system, but still get cabal's excellent dependency version calculations. Here are the main situations when I wish I had make: * Whenever I want cabal to do something that is not already common practice for cabal packages, I end up having to write a bunch of code in Setup.hs, hacking hooks, and whatnot. This always feels dirty and time consuming. * Cabal doesn't yet support parallel builds. * Cabal files that list many libraries or many executables do a lot of redundant work and the user doesn't have a fine grained way to specify which executables or libraries to build without going to a lot of extra configuration in the cabal file to add flags. * All modifications to the .cabal file require a full project rebuild, even when the changes do not impact the source or build plan. * I need to introspect the build. Perhaps it's not going as planned and I want to debug it. My only recourse at the moment is --verbose=3. I find that with the current API, using make and cabal's dependency calculations are mutually exclusive. I think the happy medium here is translating the LocalBuildInfo to a makefile (or part of a makefile). Ideally this makefile could be optionally included into another makefile. The expectation would be that the generated makefile is treated as an autogenerated file (eg., not checked into source control or statically placed on hackage). Instead it's regenerated during the configure step and then cabal or the user can invoke make to run the targets. I believe this would give us parallel builds, allow us to reuse more and recompile less, and allow us to examine the build plan. And all this would be possible by leveraging the nice statically checkable, declarative package specifications we have instead of mucking about with configure scripts or trying to write an unstructured makefile from hand and getting the rules subtly wrong. I could imagine it putting us into a harmonious state where we get the best of both worlds. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/815 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#815: Feature Request: Translate buildplan to makefile -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.6 Severity: normal | Resolution: wontfix Keywords: makefile, make | Difficulty: unknown Ghcversion: | Platform: -----------------------------+---------------------------------------------- Changes (by duncan): * status: new => closed * resolution: => wontfix Comment: This should be possible. It is what the ghc build system does. There should be enough stuff exported from the Cabal library for you to be able to do this. Indeed it should be possible to use that in a custom cabal package build system. Part of the Cabal architecture is that you can use any build system you like for a package and still get all the automated package management. It has certainly worked in the past (see franchise). If there's anything preventing it, file a ticket. I don't plan to add this feature to the Cabal library itself however. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/815#comment:1 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#815: Feature Request: Translate buildplan to makefile -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.6 Severity: normal | Resolution: wontfix Keywords: makefile, make | Difficulty: unknown Ghcversion: | Platform: -----------------------------+---------------------------------------------- Comment(by guest): Where is the documentation for this feature of getting the automated package management? The user guide doesn't appear to discuss it. It seems like actually you have to make your own tool on top of cabal or you have to implement the logic again and again in every project that wants it (inside Setup.hs). If GHC needs this functionality, and other non-ghc projects would benefit as well, what is the justification for not implementing it as part of the Cabal library? One thing I can't do with cabal that I can do with all other build systems I've used is to define new rules for processing files. For example, if I made a new preprocessor for Haskell source I would have to write custom code in every Setup.hs that needs the preprocessor currently. Being able to generate a build plan as a makefile would make it so that custom preprocessor rules could be inserted easily by end users without having to resort to hacking their Setup.hs. For me, modifying Setup.hs is a last resort. It's a desperate measure. Being forced to reimplementing the build logic for every project in a general purpose language is exactly the problem that build system DSLs like Make were designed to solve. That's why I see writing custom Setup.hs to do anything that isn't trivial as a step backwards. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/815#comment:2 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
Where is the documentation for this feature of getting the automated
#815: Feature Request: Translate buildplan to makefile -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.6 Severity: normal | Resolution: wontfix Keywords: makefile, make | Difficulty: unknown Ghcversion: | Platform: -----------------------------+---------------------------------------------- Comment(by duncan): Replying to [comment:2 guest]: package management? The user guide doesn't appear to discuss it. It's in the Cabal spec: http://haskell.org/cabal/proposal/x138.html#AEN226
It seems like actually you have to make your own tool on top of cabal or you have to implement the logic again and again in every project that wants it (inside Setup.hs).
The Setup.hs just provides a standard command line interface. Tools are expected to work with any Setup.hs that implements the interface correctly. The Setup.hs does not need to depend on the Cabal library. That's the theory. What the spec misses out however is a mechanism for the Setup.hs to depend on other Cabal packages. It's not prevented but it's essentially an untracked dependency. That's something that could be improved.
If GHC needs this functionality, and other non-ghc projects would benefit as well, what is the justification for not implementing it as part of the Cabal library?
Because different systems want to do it differently. The code that was previously in the Cabal library for this was highly ghc specific and not widely useful which is why we moved it into the ghc build system rather than in the Cabal lib.
One thing I can't do with cabal that I can do with all other build systems I've used is to define new rules for processing files. For example, if I made a new preprocessor for Haskell source I would have to write custom code in every Setup.hs that needs the preprocessor currently. Being able to generate a build plan as a makefile would make it so that custom preprocessor rules could be inserted easily by end users without having to resort to hacking their Setup.hs.
For me, modifying Setup.hs is a last resort. It's a desperate measure. Being forced to reimplementing the build logic for every project in a general purpose language is exactly the problem that build system DSLs
Prehaps I'm missing something. I don't see how users adding a build rule for a preprocessor to their package's Makefile is different to adding it to their package's Setup.hs. Perhaps the Makefile is a nicer DSL, but that's a slightly different point. The "Simple" build system actually has an almost nice way of defining preprocessors. You just give the file extension to look for and the code to run. like Make were designed to solve. That's why I see writing custom Setup.hs to do anything that isn't trivial as a step backwards. It's certainly the case that the Simple build system does not have a nice easy extension mechanism. There's two separate points here: * The Cabal spec says you can put whatever you like in the Setup.hs. This gives maximum flexibility. Implementing a build system is not trivial however (unless like the Make one it just delegates everything). * A specific build system (e.g. the Simple one) could provide some more restricted but easier to use extension DSL. The reason I think we do not yet have a nicer extension mechanism in the Simple build system goes back to the fact that it is not based on a modular dependency framework. If it were, it would be much easier to extend. Trying to make it far more extensible in its current state would be a bit of a nightmare. We did have a GSoC project on this (using a dependency based framework) but didn't get as far as we'd like. It's doable, it's just quite a bit of work. Strangely, the poor quality of the Simple build system has not been the biggest thing that users complain about, so it does not float to the top of the TODO list. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/815#comment:3 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#815: Feature Request: Translate buildplan to makefile -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.6 Severity: normal | Resolution: wontfix Keywords: makefile, make | Difficulty: unknown Ghcversion: | Platform: -----------------------------+---------------------------------------------- Comment(by guest): I just learned of another concrete case where this would be useful. People trying to debug build issues with or tweak the darcs build. Currently Ganesh (and others), redirect the output of 'cabal build --verbose=3' and then extract the exact command. If cabal could translate it's build plan to make files or even a shell friendly version this would make things easier. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/815#comment:4 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#815: Feature Request: Translate buildplan to makefile -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.6 Severity: normal | Resolution: wontfix Keywords: makefile, make | Difficulty: unknown Ghcversion: | Platform: -----------------------------+---------------------------------------------- Comment(by AntoineLatter): Presumably this would only work for packages using the 'simple' build type? -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/815#comment:5 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
participants (1)
-
Hackage