Per-component InstallDirs #2836
Comments
|
I'm going to close this for now, because implementing it properly would require both Cabal and cabal-install to take the idea of component as the central unit (for building, and install planning) more seriously. |
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 <ezyang@cs.stanford.edu>
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 <ezyang@cs.stanford.edu>
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 <ezyang@cs.stanford.edu>
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 <ezyang@cs.stanford.edu>
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 <ezyang@cs.stanford.edu>
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 <ezyang@cs.stanford.edu>
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 <ezyang@cs.stanford.edu>
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 <ezyang@cs.stanford.edu>
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 <ezyang@cs.stanford.edu>
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 <ezyang@cs.stanford.edu>
ezyang
added a commit
to ezyang/cabal
that referenced
this issue
Feb 6, 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 <ezyang@cs.stanford.edu>
ezyang
added a commit
to ezyang/cabal
that referenced
this issue
Feb 20, 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 <ezyang@cs.stanford.edu>
ezyang
added a commit
to ezyang/cabal
that referenced
this issue
Feb 20, 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 <ezyang@cs.stanford.edu>
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 <ezyang@cs.stanford.edu>
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 <ezyang@cs.stanford.edu>
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 <ezyang@cs.stanford.edu>
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 <ezyang@cs.stanford.edu>
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 <ezyang@cs.stanford.edu>
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 <ezyang@cs.stanford.edu>
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 <ezyang@cs.stanford.edu>
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 <ezyang@cs.stanford.edu>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, the install paths for binaries, libraries, and all other fun stuff is balled up into a single data structure
InstallDirs. This kind of makes sense, if you think you are installing a "package". But you're really not; you may be installing any combination of components associated with the package. From this perspective, having all ofInstallDirsin a single data structure is hogwash.The reason it is nonsensical is that the standard install paths substitution includes a variable for
$ipid. Pray tell, what is this supposed to mean for non-library components? If you use$ipidin binpath, thinking that this will let you install multiple copies of an executable for different dependency resolutions, you're wrong: if the library dep resolves the same way the executables will all clobber each other (since this "ipid" is derived purely from the library).Another piece of nonsense: currently, the code is organized around the idea that we install "packages". That's nonsense, sometimes you just want to install the components you, you know, actually built. (#2780) Our installation code should be organized on a per-COMPONENT basis. And if I'm installing an executable, why am I computing library paths again?
InstallDirs should be atomized into a set of data structures, one per component, and install/configure modified to keep them separate accordingly. We should report install paths on a per component basis, rather than assume that there's one said of paths that applies to the entire package.
The text was updated successfully, but these errors were encountered: