step into duktape with symbols

[vinniefalco]

duktape needs to always have debug symbols and we should always be able to step into duktape functions in either optimized or non-optimized builds.

[alandefreitas]

Why not just respect the user's decision (including us as the "user")?

• Debug: non-optimized with debug symbols
• Release: optimized without debug symbols
• RelWithDebInfo: optimized with debug symbols

Then LLVM uses RelWithDebInfo as an exception because of a practical technical constraint.

[vinniefalco]

Debug
  MrDox:   no optimization, no iterator debugging
  llvm:        no optimization, no iterator debugging
  fmtlib:     optimization, no iterator debugging
  duktape: no optimization, no iterator debugging

DebugWithRel
  MrDox:   no optimization, no iterator debugging
  llvm:        optimization, no iterator debugging
  fmtlib:     optimization, no iterator debugging
  duktape: optimization, no iterator debugging

RelWithDebInfo
  MrDox:   optimization, no iterator debugging
  llvm:        optimization, no iterator debugging
  fmtlib:     optimization, no iterator debugging
  duktape: optimization, no iterator debugging

[alandefreitas]

1) Debug and DebugWithRel are the same here. 2) Release is also missing. What happens when the user calls Release? 3) Some of these combinations might require new LLVM binaries. 4) All factors you listed have no iterator debugging. Is that on purpose? This will cause lots of conflicts since all dependencies want iterator debugging in Debug. We would be forcing the compiler to not do what it does for our libraries and the dependencies. It might even require patches in their build scripts.

To avoid most of these problems I think I would simplify it to:

• Debug

  • MrDox: no optimization, iterator debugging to avoid ODR
  • llvm: RelWithDebInfo: optimization, iterator debugging to avoid ODR (In general we would use Debug but RelWithDebInfo is there just to make it faster. LLVM with RelWithDebInfo won't include iterator debugging though so we might need to build it as Debug and give it the -O3 flag ourselves)
  • fmtlib/duktape: Debug: whatever optimization the package provides, iterator debugging to avoid ODR

• Release

  • MrDox: optimization, no iterator debugging to avoid ODR
  • llvm: Release: optimization, no iterator debugging to avoid ODR, no debug info
  • fmtlib/duktape: Release: no iterator debugging

• RelWithDebInfo

  • MrDox: optimization, no iterator debugging to avoid ODR, debug info
  • llvm: RelWithDebInfo: optimization, no iterator debugging to avoid ODR, debug info (RelWithDebInfo)
  • fmtlib/duktape: Release: no iterator debugging (external packages will only provide Debug and Release / the fetchcontent version can use RelWithDebInfo)

• DebugWithRel: not a valid CMake parameter. The valid values are Debug, Release, RelWithDebInfo and MinSizeRel.

[vinniefalco]

That is not acceptable; we need to be able to step in to unoptimized builds of LLVM. All targets must have symbols: there is no use-case for not having symbols.

[alandefreitas]

That is not acceptable; we need to be able to step in to unoptimized builds of LLVM

Where did I say we wouldn't?

All targets must have symbols: there is no use-case for not having symbols

Unless there's clarification I think this statement is too broad. I hope you're not saying all Release builds in the world are stupid. ("Release" meaning optimization + no debug symbols as usual)

I don't think people see the Release build as a "use-case" or a "functional feature" of the application. In any case, they see it, or also see it, as a trade-off between bloating the size of the executable by many times for debug symbols that might or might not be useful.

And they solve this trade-off by providing different build types that have specific meanings and using each build type in a context. Creating a verbal dispute about what these build types should mean and forcing CMake to pretend one build type (RelWithDebInfo) is another build type (Release) after the convention is established does nothing to solve this underlying trade-off. It only creates confusion for users and conflicts with other libraries. Some of these conflicts are often impossible to solve given the expectations of package managers.

If we want to see these build types as "use-cases", then we could say a "use case" for Release is downloading and running mrdox in CI when the user would prefer to download smaller binary because he cares more about saving resources than about eventually seeing these symbols he could see outside CI.

But even if this is not considered a valid use case for some arbitrary reason, creating a verbal dispute about what these terms mean doesn't help with anything. We could just say we provide binaries compiled as RelWithDebInfo and call it a day. Intentionality is clear, users are not confused, and libraries have no conflicts.