Re: GDB testsuite overrides default_target_compile and breaks

[Tom Tromey <tromey@adacore.com>]

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