-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Fix build settings #357
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
Fix build settings #357
Conversation
@@ -263,7 +263,9 @@ endif | |||
|
|||
.PHONY: build | |||
build: ${TARGET} | |||
ifneq (${TARGET},failtarget) | |||
${MAKE} settings |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Going recessive on makefiles is general what we are trying to get away from.
if you need to do this you need to the build: ${TARGET} to build: settings using ifndef.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not really sure what you mean. Sorry. Can you try explaining differently or using a code example of how this should be done?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be done like this:
ifneq (${TARGET},failtarget)
build: ${TARGET}
else
build: failtarget
endif
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure how that is going to fix the problem I am trying to solve. Perhaps I should explain the issue more. Right now if I just do make
with no TARGET
specified, the help is displayed as well as the settings. I don't really find that necessary. This commit prevents the settings from being displayed in that occurrence.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i will just shut my cake hole now ;)
Yeah i did not get it on a few levels.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Haha. OK. No problem. Hopefully, things are more clear now? I'm open to making things better and taking feedback. It is no problem.
Personal input and nothing more:
|
This makes sense. I never read this before or I just merely glanced over your thinking from the other pull request. I think in general that logic is fine. If you are in opposition of removing the Perhaps I am still misunderstanding something. |
no feelings ;) i just complete miss read what you were doing on this pull request. This is 100% my fault ;) |
OK. No worries. |
I should make it clear I don't care enough to be in opposition of anything that goes on with settings. I mean if people like it will stay. They don't it will go, but never by my hand :) I might push to make the build visually clean to users so that when it outputs errors it feels like a bug. Less griberish on the screen for users makes the software seam more complete and finished. Redis is my example of this. People open up bug reports for warning messages and I think that is great. |
Thanks for clarifying. Lets get this merged? |
Maybe you can extend the condition until the end of build, cause the green output |
Per the suggestion of cgzones in ossec#357, the if statement has been extended so that the completion message is not displayed when doing a build for 'failtarget'.
@cgzones I update the pull request with the suggested changes. |
No description provided.