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

Jump to bottom

[SR-10787] Add type-safe flag for "include debug info" rather than unsafeFlags(["-g"]) #4708

Open
ktoso opened this issue May 29, 2019 · 4 comments
Open

[SR-10787] Add type-safe flag for "include debug info" rather than unsafeFlags(["-g"]) #4708

ktoso opened this issue May 29, 2019 · 4 comments
Labels
enhancement

Comments

@ktoso
Copy link
Member

ktoso commented May 29, 2019

Previous ID SR-10787
Radar None
Original Reporter @ktoso
Type New Feature
Additional Detail from JIRA
Votes 0
Component/s Package Manager
Labels New Feature
Assignee None
Priority Medium

md5: 7fbebb0505ab2670a5b40caea8541a32

Issue Description:

Server side libraries which want to have nice crash information (in -c release mode), even if the end-user of the library forgot to compile their library using -g may want to include the -g flag in all of their targets, so regardless of user forgetting to add it or not, at least that library would carry debug info, which could be used in backtraces etc.

Currently it seems there is no predefined setting for this, so I resorted to:

import PackageDescription

let targets: [PackageDescription.Target] = [
    .target(
        name: "Something",
        dependencies: [],
        swiftSettings: [SwiftSetting.unsafeFlags(["-g"])]
    )
]

A type-safe option for this setting would be beneficial, since many (if not all) users on the server-side should include this option when developing their apps, in order to get better traces when things go wrong.

Examples of libraries depending on this:

Example impl:

/// Pre-defined well-known Swift build flags
extension SwiftSetting {
    /// Emit debug info. This is the preferred setting for debugging with LLDB.
    public static let emitDebugInfo: PackageDescription.SwiftSetting = SwiftSetting(name: "emitDebugInfo", value: ["-g"], condition: nil)
}

Docs from command line: -g Emit debug info. This is the preferred setting for debugging with LLDB.

I'd be happy to PR this if you think it makes sense.
@belkadan
Copy link

I don't see why this would be a per-target setting.

@belkadan
Copy link

(I also don't see why release builds wouldn't always have at least -gline-tables-only.)

@ankitspd
Copy link
Member

I don't think it makes sense for library authors to control this flag. You probably want to enable this for all targets which can be done using `swift build -c release -Xswiftc -g`.

@ktoso
Copy link
Member Author

ktoso commented May 30, 2019

(I also don't see why release builds wouldn't always have at least -gline-tables-only.)

This would be quite fantastic actually!

It would indeed be awesome to have this as default behavior (always enable -gline-tables-only for release builds), but would it really be possible? I think it'd be quite a great step in improving quality of life on the (linux) server side, but would people who care much about binary size not be against this (maybe people realistically run with this option enabled anyway in apps?)?

I don't think it makes sense for library authors to control this flag. You probably want to enable this for all targets which can be done using `swift build -c release -Xswiftc -g`.

The actual goal here is more like: make it easier for people to always "do the right thing", and on the server running without at-least -gline-tables-only is a bad idea in general.

I'd love to be able to tell users "you're doing a server app, include this setting in your build" rather than having to remember to use the flag everywhere and always when compiling (manually, on CI, when testing, when building...). What would be a good way of achieving this?

You are also right that it would not have to be target specific... but having some way of having it defined in the build, rather than having to always and everywhere remember about the flag would be excellent.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@shahmishal shahmishal transferred this issue from apple/swift May 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@ktoso @tomerd @belkadan @ankitspd