This is a follow-up of my previous approach [1] on separating the support of additional platforms from the official repository:
In addition to the zynq_qemu SPEC variable that is already existent in the official repository, I'd like to add SPEC variables like `zynq_parallella` and `zynq_zedboard` to genode-world. However, I just ran into a conceptual problem that I'd like to discuss here.
First, I can place a core.mk in genode-world/lib/mk/specs/zynq_parallella, which is then used as soon as I change the SPECS from zynq_qemu to zynq_parallella. I am also able to set the include directories properly.
The point where I got stuck, however, is that I need to include the less-specific configuration files within base-hw, which I achieve by the following line:
include $(call select_from_repositories,lib/mk/spec/zynq/core.inc)
Now, the issue is that including makefiles from other repositories won't work properly. This is due to the fact that $REP_DIR (used e.g. in core.inc) will evaluate to `[...]/repos/world` and not `[...]/repos/base-hw`.
Do you have any idea on how to work around this or even on how to improve the build system in order to support this use case?
Cheers Johannes
Hi Johannes,
The point where I got stuck, however, is that I need to include the less-specific configuration files within base-hw, which I achieve by the following line:
include $(call select_from_repositories,lib/mk/spec/zynq/core.inc)
Now, the issue is that including makefiles from other repositories won't work properly. This is due to the fact that $REP_DIR (used e.g. in core.inc) will evaluate to `[...]/repos/world` and not `[...]/repos/base-hw`.
Do you have any idea on how to work around this or even on how to improve the build system in order to support this use case?
Hosting core.mk files outside the base-hw repository is a new pattern for us, but I see the appeal.
REP_DIR always points to the repository where the target resides - in your case, this is the core.mk library. The simplest solution would be to replace the occurrences of REP_DIR in core.inc by a new variable BASE_HW_DIR, which has to be defined by the one to includes core.inc. The core.mk files within the base-hw repository would simply define to as $(REP_DIR) but your "foreign" core.mk file could set the variable explicitly to the location of the base-hw repository.
Would that solve your problem?
Cheers Norman
Hi Johannes,
The point where I got stuck, however, is that I need to include the less-specific configuration files within base-hw, which I achieve by the following line:
include $(call select_from_repositories,lib/mk/spec/zynq/core.inc)
Now, the issue is that including makefiles from other repositories won't work properly. This is due to the fact that $REP_DIR (used e.g. in core.inc) will evaluate to `[...]/repos/world` and not `[...]/repos/base-hw`.
Do you have any idea on how to work around this or even on how to improve the build system in order to support this use case?
Hosting core.mk files outside the base-hw repository is a new pattern for us, but I see the appeal.
REP_DIR always points to the repository where the target resides - in your case, this is the core.mk library. The simplest solution would be to replace the occurrences of REP_DIR in core.inc by a new variable BASE_HW_DIR, which has to be defined by the one to includes core.inc. The core.mk files within the base-hw repository would simply define to as $(REP_DIR) but your "foreign" core.mk file could set the variable explicitly to the location of the base-hw repository.
Would that solve your problem?
Yes, that would solve the problem. Thank you.