In preparation for adding support for building lib32 on arm64,
add a list of architecture-specific include directories,
LIBCOMPAT_INCLUDE_DIRS, then replace the architecture-specific
ifdefs throughout the file with simple loops. Another commit
will add a definition of LIBCOMPAT_INCLUDE_DIRS for aarch64.
Details
Details
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 52574 Build 49465: arc lint + arc unit
Event Timeline
| Makefile.inc1 | ||
|---|---|---|
| 1088 | Leave these as usr/include to match surrounding code? | |
| Makefile.inc1 | ||
|---|---|---|
| 1088 | I debated that. I don't know if INCLUDEDIR could be overridden here. I guess other uses have usr/include though. | |
| Makefile.inc1 | ||
|---|---|---|
| 1088 | Yeah; whether it makes sense to use INCLUDEDIR here throughout I don't know, probably not given the use of mtree files that hard-code usr/include, but even if it does that's a bigger change to do throughout | |
Comment Actions
LGTM with lone comment addressed
| Makefile.inc1 | ||
|---|---|---|
| 1423 | This didn't have -p before; probably it should, but that's a separate change that shouldn't be here (and you shouldn't feel compelled to do :)) | |
| Makefile.inc1 | ||
|---|---|---|
| 1423 | That would mean a target more than one level down from usr/include would need to have its parent(s) listed separately, and in order. While generalizing, why not generalize? | |
| Makefile.inc1 | ||
|---|---|---|
| 1423 | Well the METALOG code needs the parents to be listed separately otherwise they won't end up in the file, so that restriction is totally fine | |