#1 Makefile: more fixes.

Closed
msc wants to merge 1 commits from msc/pEpJSONServerAdapter:master into master
msc commented 5 months ago
  • Don't use implicit rules. Thy hide bugs.
  • Build release builds with debug symbols.
  • Fix install/uninstall.
- Don't use implicit rules. Thy hide bugs. - Build release builds with debug symbols. - Fix install/uninstall.
msc added 1 commit 5 months ago
heck commented 5 months ago
Collaborator

Roker: please integrate marcels changes, but not the removal of the implicit rules as it contradicts with adapter-land-makefile-style-guide: "We make use of implicit rules to the extent possible."

Roker: please integrate marcels changes, but not the removal of the implicit rules as it contradicts with adapter-land-makefile-style-guide: "We make use of implicit rules to the extent possible."
heck commented 5 months ago
Collaborator

...because we like our makefiles, short, pretty and standard.

...because we like our makefiles, short, pretty and standard.
heck commented 5 months ago
Collaborator

we will never see this in any of the makefiles we maintain:
MAKEFLAGS += --no-builtin-rules

we will never see this in any of the makefiles we maintain: MAKEFLAGS += --no-builtin-rules
msc commented 5 months ago
Poster

@heck

we will never see this in any of the makefiles we maintain:

Maybe write that down somewhere? Though tbh I have no idea where one would write that down, so maybe it is there already. Maybe also write down where such things are written down... Front page of https://dev.pep.security/ maybe?

@heck > we will never see this in any of the makefiles we maintain: Maybe write that down somewhere? Though tbh I have no idea where one would write that down, so maybe it is there already. Maybe also write down *where* such things are written down... Front page of https://dev.pep.security/ maybe?
heck commented 5 months ago
Collaborator

it is written down. i assumed you have read it yourself...
https://pep.foundation/jira/browse/JSON-193

but, marcel, you should not have to worry about this, since you are not part of the adapter team. (or are you and i dont know it___?)

It is Rokers job to mantain the makefiles for the pEpJSONAdapter.

I thought about making a wiki page, but since i dont have 20 people in my team, but more like 2 or so... i might do it, still...

it is written down. i assumed you have read it yourself... https://pep.foundation/jira/browse/JSON-193 but, marcel, you should not have to worry about this, since you are not part of the adapter team. (or are you and i dont know it___?) It is Rokers job to mantain the makefiles for the pEpJSONAdapter. I thought about making a wiki page, but since i dont have 20 people in my team, but more like 2 or so... i might do it, still...
msc commented 5 months ago
Poster

Well, JSON-193 and this PR where kind of concurrent. But yes, things do get written down, and that is great!

And no, I am not part of the adapter team, I am not in any way responsible for that, but it is still very much my problem. I guess I was in a deployment role for a while, but also as a developer, I need to compile adapters on sometimes weird platforms and that involves fixing the Makefiles as required. I could open a ticket for each of the problems, but fixing it myself is just much faster.

So that might explain why I am not aware of the Adapter Makefile conventions, and that is I think a very good reason why they should be documented in an easy to find place (which, ofc, we need to agree on company/project wide).

Ofc this is really not at all about the changes in this PR and also not really just about adapter Makefiles. More like, in general, documentation is not for the people who have to deal with sth. every day (they tend to know stuff), but for the people for whom whatever is just yet another thing that needs to get out of the way before the actual work can start.

Well, JSON-193 and this PR where kind of concurrent. But yes, things do get written down, and that is great! And no, I am not part of the adapter team, I am not in any way *responsible* for that, but it is still very much my problem. I guess I was in a deployment role for a while, but also as a developer, I need to compile adapters on sometimes weird platforms and that involves fixing the Makefiles as required. I could open a ticket for each of the problems, but fixing it myself is just _much_ faster. So that might explain why I am not aware of the Adapter Makefile conventions, and that is I think a very good reason why they should be documented in an easy to find place (which, ofc, we need to agree on company/project wide). Ofc this is really not at all about the changes in this PR and also not really just about adapter Makefiles. More like, in general, documentation is not for the people who have to deal with sth. every day (they tend to know stuff), but for the people for whom _whatever_ is just yet another thing that needs to get out of the way before the actual work can start.
roker closed this pull request 5 months ago
Please reopen this pull request to perform a merge.
Sign in to join this conversation.
No reviewers
No Label
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This pull request currently doesn't have any dependencies.

Loading…
There is no content yet.