-
Edward Z. Yang authored
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. #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>
90e908b8