Use per-component cabal_macros.h #1893

bennofs · 2014-05-22T14:39:00Z

I have a project that builds a library and has some benchmarks. Now, everytime I switch the benchmarks from disabled to enabled (I don't enable them all the time to make building faster when only working on the library), cabal_macros.h changes because it has different dependencies than the library. This causes parts of the library to be recompiled. Using a per-component cabal_macros.h would solve the issue.

The text was updated successfully, but these errors were encountered:

ezyang · 2016-01-11T18:47:08Z

I think in the course of #3022 I will fix this bug.

ezyang · 2016-01-11T19:17:00Z

OK, here's the problem: if we have separate cabal_macros.h per library, the preprocessors need to know about what component they are building. Currently, the Preprocessor interfaces does not get this information, so we'd need to extend this interface. Unfortunately, the preprocessor hooks are a very commonly used interface in Custom setup files, so we need to decide if we're going to break it for more recent Cabal, or try to support this in a backwards compatible way.

But actually, I think this is OK, because with custom-setup, people who depend on old Cabal won't pick up a breaking version of Cabal.

By the way, extension point is probably extending

type PPSuffixHandler
    = (String, BuildInfo -> LocalBuildInfo -> PreProcessor)

to also get a ComponentLocalBuildInfo.

23Skidoo · 2016-01-11T19:59:05Z

But actually, I think this is OK, because with custom-setup, people who depend on old Cabal won't pick up a breaking version of Cabal.

You mean setup-depends? Yes, that's what it's for. We should start taking advantage of it!

This commit is a number of refactorings that I needed to do while fixing bugs with internal libraries support. - With internal libraries, it becomes especially clear that cabal_macros.h and Paths_foo.hs need to be done per-component. It is done! This change breaks BC in an important way: the preprocessor interface now takes a ComponentLocalBuildInfo along with the BuildInfo and LocalBuildInfo. This means that if you implemented a custom preprocessor, or called 'preprocessComponent' in a custom Setup, you will have to make sure you pass the right ComponentLocalBuildInfo. Some sub-notes: - While I was mucking about cabal_macros.h, I updated it to have two new macros: CURRENT_COMPONENT_ID (an alias for CURRENT_PACKAGE_KEY, but using modern terminology) and LOCAL_COMPONENT_ID (which refers to the public library; we use this in Cabal's test suite but it's unclear what the general utility of this is. See the TODO.) - checkForeignDeps has a hack where we hardcode the cabal_macros.h of the main library. If we did the foreign dep check for every component individually that would be better, but I didn't want to roll it into this patch. - The other piece I needed for internal libraries was per-component install directories; otherwise, internal libraries clobber each other. absoluteInstallDirs now takes a ComponentId, which is used to determine what '$libname' expands to. Generally, InstallPaths must be computed per component, c.f. haskell#2836. We're not TRULY per-component install paths, since some files are installed for the "per-package" InstallPaths (the one we computed for the library as a whole), but for libraries we have to compute InstallPaths for each one. - While doing this, ComponentLocalBuildInfo grew a new 'componentId' field for non-library things. This lets us treat InstallPaths expansion uniformly. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

haskell#1893) Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>