Development for Building Kubernetes is inaccurate

[vitorfhc]

Describe the issue

The documentation suggests using GOGCFLAGS="-N -l".

In the Makefile we have another way to set debug mode, which is using DBG=1.

If we check the code for hack/lib/golang.sh(link), it sets -N -l for us when DBG=1. Otherwise, it sets goldflags="${goldflags} -s -w".

Having goldflags="${goldflags} -s -w" and gogcflags="${GOGCFLAGS:-} all=-N -l" is going to make a succesful build, but when trying to use Delve for debugging we get this error: could not launch process: could not open debug info - debuggee must not be built with 'go run' or -ldflags='-s -w', which strip debug info.

We should change this documentation to suggest using DBG instead.

[vitorfhc]

/sig docs

[Pro-Coder04]

/assign

[mrbobbytables]

/remove-sig docs /sig contributor-experience /area developer-guide

[sreekaransrinath]

diff --git a/contributors/devel/development.md b/contributors/devel/development.md
index 527b5d77..00ebe0a3 100644
--- a/contributors/devel/development.md
+++ b/contributors/devel/development.md
@@ -357,10 +357,10 @@ The Kubernetes build system defaults to limiting the number of reported Go compi
 make WHAT="cmd/kubectl" GOGCFLAGS="-e"
 
-If you need to use debugging inspection tools on your compiled Kubernetes executables, add `-N -l` to `GOGCFLAGS`. For example:
+If you need to use debugging inspection tools on your compiled Kubernetes executables, set DBG=1. For example:
 
-make WHAT="cmd/kubectl" GOGCFLAGS="-N -l"
+make WHAT="cmd/kubectl" DBG=1
 
 To cross-compile Kubernetes for all platforms, run the following  #command:

Hey,

@mrbobbytables - do you think this doc change makes sense? @Pro-Coder04 Are you working on this or do you mind if I submit a quick PR?

[Pro-Coder04]

@sreekaransrinath you can go ahead with your PR

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[vitorfhc]

Any updates on this merge?

[aojea]

/assign @thockin