Support installing headers in uhal properly
#55
Comments
ericonr
added a commit
to lnls-dig/afc-epics-ioc
that referenced
this issue
Oct 4, 2024
This simplifies an eventual containerized build of afc-epics-ioc using epics-in-docker, allowing the μHAL build script to simply install it directly into system directories. We should eventually stop requiring an -I flag for cases where the headers are installed to default system locations. This is tracked by a uhal issue [1]. [1] lnls-dig/uhal#55
ericonr
added a commit
to lnls-dig/afc-epics-ioc
that referenced
this issue
Oct 4, 2024
This simplifies an eventual containerized build of afc-epics-ioc using epics-in-docker, allowing the μHAL build script to simply install it directly into system directories. We should eventually stop requiring an -I flag for cases where the headers are installed to default system locations. This is tracked by a uhal issue [1]. [1] lnls-dig/uhal#55
ericonr
added a commit
to lnls-dig/afc-epics-ioc
that referenced
this issue
Oct 4, 2024
This simplifies an eventual containerized build of afc-epics-ioc using epics-in-docker, allowing the μHAL build script to simply install it directly into system directories. We should eventually stop requiring an -I flag for cases where the headers are installed to default system locations. This is tracked by a uhal issue [1]. [1] lnls-dig/uhal#55
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, library users need to use
-I${include_dir}/uhalto be able to include library headers.They should be able to omit any
-Iflag if the headers are installed in a default system header. This means using#include <uhal/...>in public headers and client code. For this issue, the relevant part is fixing public headers.A good example of how to do it (which saves us the trouble of listing header files, too!) comes from wlroots
This problem was called out in lnls-dig/afc-epics-ioc#43 (comment)
The text was updated successfully, but these errors were encountered: