I trimmed the cc list down to just gdb and dejagnu.
Jacob> What is needed in brief:
Jacob> (1) Merge the features of default_target_compile that the GDB
Jacob> testsuite depends on upstream for 1.6.3.
Jacob> (2) Find the actual extensibility that GDB needs here and add that
Jacob> support to the default_target_compile rewrite slated for 1.6.4.
Sounds reasonable to me.
Jacob> The changes were to an internal component and broke an out-of-tree
Jacob> copy of same. I have to draw a line somewhere, and "monkeypatching
Jacob> the core is not supported and can break" is necessary for DejaGnu to
Jacob> develop at all.
FWIW this makes sense to me. I think it's never been a great idea to
have this override in gdb. Dejagnu wasn't very actively maintained for
a long time, and had low engagement from gdb developers, so it was more
like a convenient way to move forward.
Jacob> Monkeypatching the DejaGnu core is not supported and cannot be
Jacob> supported long-term.
gdb does it other spots as well. For example, check-test-names.exp
overrides log_summary and reset_vars that gdb can show duplicated test
names, and gdb.exp renames "cd" to avoid problems with relative log file
names.
Jacob> GDB seems to have also extended default_target_compile, so a
Jacob> discussion on this is needed because there seems to be a need for some
Jacob> kind of language extensibility feature to allow new
Jacob> language-default-selector options to be defined without overriding the
Jacob> entire default_target_compile procedure
Yes, that would be good to have. I think this has been patched when a
new language is added to gdb; changing this function to work in some
extensible way would be a nice improvement... while there are no
concrete plans I know of to add new languages to gdb, one never knows
when someone may show up with patches.
Jacob> If I understand correctly, merging the features currently carried in
Jacob> gdb/testsuite/lib/future.exp upstream will cause all existing GDB
Jacob> releases to correctly use the upstream version of
Jacob> default_target_compile, making the partial reversion patch
Jacob> unnecessary.
Yes, assuming that gdb's detection code continues to work. It does
this:
if {[info procs find_gnatmake] == ""} {
rename gdb_find_gnatmake find_gnatmake
set use_gdb_compile 1
}
# ... sequence of such checks ...
if {$use_gdb_compile} {
catch {rename default_target_compile {}}
rename gdb_default_target_compile default_target_compile
}
Anyway, I compared gdb_default_target_compile with
default_target_compile. I think there are two kinds of changes.
One is the addition of new languages, namely Rust and Go. This seems
relatively straightforward.
The other is the addition of "early_flags":
if {[regexp "^early_flags=" $i]} {
regsub "^early_flags=" $i "" tmp
append early_flags " $tmp"
}
...
switch $type {
"object" {
set opts "$early_flags $add_flags $sources"
}
... etc
This seems to be needed to adapt to some distro-specific compiler
issues. One example is:
if { [test_compiler_info "gcc-*"] || [test_compiler_info
"clang-*"] } {
# Undo debian's change in the default.
# Put it at the front to not override any user-provided
# value, and to make sure it appears in front of all the
# shlibs!
lappend new_options "early_flags=-Wl,--no-as-needed"
}
I can write some patches to merge this stuff in.
Tom
