Use per-component cabal_macros.h #1893
Labels
Milestone
Comments
|
I think in the course of #3022 I will fix this bug. |
|
OK, here's the problem: if we have separate 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 to also get a |
You mean |
ezyang
added a commit
to ezyang/cabal
that referenced
this issue
Jan 12, 2016
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 <[email protected]>
ezyang
added a commit
to ezyang/cabal
that referenced
this issue
Jan 12, 2016
haskell#1893) Signed-off-by: Edward Z. Yang <[email protected]>
Merged
ezyang
added a commit
to ezyang/cabal
that referenced
this issue
Jan 12, 2016
haskell#1893) Signed-off-by: Edward Z. Yang <[email protected]>
Closed
ezyang
added a commit
to ezyang/cabal
that referenced
this issue
Jan 13, 2016
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 <[email protected]>
ezyang
added a commit
to ezyang/cabal
that referenced
this issue
Jan 13, 2016
haskell#1893) Signed-off-by: Edward Z. Yang <[email protected]>
ezyang
added a commit
to ezyang/cabal
that referenced
this issue
Jan 14, 2016
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 <[email protected]>
ezyang
added a commit
to ezyang/cabal
that referenced
this issue
Jan 14, 2016
haskell#1893) Signed-off-by: Edward Z. Yang <[email protected]>
ezyang
added a commit
to ezyang/cabal
that referenced
this issue
Jan 15, 2016
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 <[email protected]>
ezyang
added a commit
to ezyang/cabal
that referenced
this issue
Jan 15, 2016
haskell#1893) Signed-off-by: Edward Z. Yang <[email protected]>
ezyang
added a commit
to ezyang/cabal
that referenced
this issue
Jan 19, 2016
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 <[email protected]>
ezyang
added a commit
to ezyang/cabal
that referenced
this issue
Jan 19, 2016
haskell#1893) Signed-off-by: Edward Z. Yang <[email protected]>
ezyang
added a commit
to ezyang/cabal
that referenced
this issue
Jan 27, 2016
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 <[email protected]>
ezyang
added a commit
to ezyang/cabal
that referenced
this issue
Jan 27, 2016
haskell#1893) Signed-off-by: Edward Z. Yang <[email protected]>
ezyang
added a commit
to ezyang/cabal
that referenced
this issue
Jan 28, 2016
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 <[email protected]>
ezyang
added a commit
to ezyang/cabal
that referenced
this issue
Jan 28, 2016
haskell#1893) Signed-off-by: Edward Z. Yang <[email protected]>
ezyang
added a commit
to ezyang/cabal
that referenced
this issue
Feb 2, 2016
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 <[email protected]>
ezyang
added a commit
to ezyang/cabal
that referenced
this issue
Feb 2, 2016
haskell#1893) Signed-off-by: Edward Z. Yang <[email protected]>
ezyang
added a commit
to ezyang/cabal
that referenced
this issue
Feb 2, 2016
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 <[email protected]>
ezyang
added a commit
to ezyang/cabal
that referenced
this issue
Feb 2, 2016
haskell#1893) Signed-off-by: Edward Z. Yang <[email protected]>
ezyang
added a commit
to ezyang/cabal
that referenced
this issue
Mar 5, 2016
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 <[email protected]>
ezyang
added a commit
to ezyang/cabal
that referenced
this issue
Mar 5, 2016
haskell#1893) Signed-off-by: Edward Z. Yang <[email protected]>
ezyang
added a commit
to ezyang/cabal
that referenced
this issue
Mar 16, 2016
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 <[email protected]>
ezyang
added a commit
to ezyang/cabal
that referenced
this issue
Mar 16, 2016
haskell#1893) Signed-off-by: Edward Z. Yang <[email protected]>
ezyang
added a commit
to ezyang/cabal
that referenced
this issue
Mar 16, 2016
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 <[email protected]>
ezyang
added a commit
to ezyang/cabal
that referenced
this issue
Mar 16, 2016
haskell#1893) Signed-off-by: Edward Z. Yang <[email protected]>
ezyang
added a commit
to ezyang/cabal
that referenced
this issue
Mar 18, 2016
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 <[email protected]>
ezyang
added a commit
to ezyang/cabal
that referenced
this issue
Mar 18, 2016
haskell#1893) Signed-off-by: Edward Z. Yang <[email protected]>
ezyang
added a commit
to ezyang/cabal
that referenced
this issue
Mar 28, 2016
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 <[email protected]>
ezyang
added a commit
to ezyang/cabal
that referenced
this issue
Mar 28, 2016
haskell#1893) Signed-off-by: Edward Z. Yang <[email protected]>
ezyang
added a commit
to ezyang/cabal
that referenced
this issue
Mar 28, 2016
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 <[email protected]>
ezyang
added a commit
to ezyang/cabal
that referenced
this issue
Mar 28, 2016
haskell#1893) Signed-off-by: Edward Z. Yang <[email protected]>
ezyang
added a commit
to ezyang/cabal
that referenced
this issue
Mar 29, 2016
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 <[email protected]>
ezyang
added a commit
to ezyang/cabal
that referenced
this issue
Mar 29, 2016
haskell#1893) Signed-off-by: Edward Z. Yang <[email protected]>
ezyang
added a commit
to ezyang/cabal
that referenced
this issue
Mar 29, 2016
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 <[email protected]>
ezyang
added a commit
to ezyang/cabal
that referenced
this issue
Mar 29, 2016
haskell#1893) Signed-off-by: Edward Z. Yang <[email protected]>
|
#3022 has been merged, I believe that this is fixed now. |
This was referenced Jul 16, 2016
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.hchanges 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: