Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

make control function "error" is nice for users but breaks introspection of dependencies #91

Closed
klauer opened this issue Aug 15, 2022 · 1 comment

Comments

@klauer
Copy link
Contributor

klauer commented Aug 15, 2022

Lines such as this that employ the "control function" error defined by GNU make:
https://github.com/pcdshub/ads-ioc/blob/b2cb4a015cb062dc2be62a38f6418c7551e92f76/configure/RELEASE#L47

Are useful for debugging when trying to build ads-ioc and having a missing dependency.
However, it breaks introspection of dependencies via tools such as whatrecord deps (or epics-sumo, presumably) if dependencies are missing.

I think it may be useful to introduce a convention wherein:

  • DEPENDENCY_CHECKER gets set to 1 by tools like whatrecord (à la typing.TYPE_CHECKING)
  • If unset (DEPENDENCY_CHECKER=0), $(error) get called as usual
  • If set (DEPENDENCY_CHECKER=1), either no output or some warning text could take place of $(error):
    • Warnings could be picked up by the tool or dropped

This could look like:

_DEPENDENCY_CHECKER ?= 0

ifneq ($(_DEPENDENCY_CHECKER),1)

# Check for valid EPICS_BASE
ifeq ($(wildcard $(EPICS_BASE)/include),)
$(error Invalid EPICS_BASE: $(EPICS_BASE)/include)
endif

endif
@klauer klauer changed the title make control function "error" is nice but breaks introspection of dependencies make control function "error" is nice for users but breaks introspection of dependencies Aug 15, 2022
@klauer
Copy link
Contributor Author

klauer commented Sep 7, 2022

Wrapped this into #86 - closing

@klauer klauer closed this as completed Sep 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant