Re: integrated -save-temps and the death of specs

[Aldy Hernandez <aldyh at redhat dot com>]

On Tuesday, March 19, 2002, at 09:41  PM, Richard Kenner wrote:

>     i got very upset at specs files today and decided to start the 
> painful
>     process towards getting rid of them altogether.
>
> I think that would be a major step *backwards*.  The advantage of specs
> file is that you can make changes to the way commands are called without
> having to recompile anything.

the only good argument i have seen for spec files have been run-time
changes to the driver-- ala, user level spec files.  vendor X wants
to override defaults and link in different things when -mfoo is
specified.  other than that, the benefits are too little for the
amount of unmaintainability, not te mention-- spec files are close
to undebuggable.

i agree that we have to provide a mechanism for user configurability,
but not at the expense of unreadability.  who can argue that the spec
file at the end of this message is readable, easy to update, and
debuggable? (that's just a random one picked).

and this is not even taking into account the myraid of:

	#undef SOME_SPEC
	#define SOME_SPEC

that goes around in some of the backends.  i think you have pointed
out in the past that conditional compilation is suboptimal for
maintainability, but in the some specs cases, virtually unavoidable.

i don't see any reason to use spec files in config/*.h files.
maybe spec files are useful for at the user-level so they don't have
to recompile the driver.  *that's* useful, but anything in .h files
will need to be recompiled anyhow, so it just adds complexity to
the compiler.

i am nowhere near suggesting to get rid of them, but to provide an
alternate mechanism for achieving the same functionality in just
plain C for non user-level things. ...for things that you'd need to
recompile anyhow.

furthermore, the spec file semantics are too limiting.  as part of
my changes, if keeping spec files for user-level tweaks proved to
be imperative, i propose we also enhance it's syntax to simplify
their usage (ands, ors, etc).

lastly, considering the spec file at the bottom... what's easier
to read, maintain, *and* debug-- the spec file, or it's C
counterpart?

(and you could even have *one* STARTFILE callback for the entire
backend.  neat).

char *
mips_startfile(thunk stuff)
{
   char lib_32bit_path[] = "/usr/lib32";
   char lib_64bit_path[] = "/usr/lib64";
   char *lib_path = NULL;

   if (!optionp("shared"))
     return NULL;

   if (optionp("mabi=64"))
     lib_path = lib_64bit_path;
   else if (optionp("mabi=n32"))
     lib_path = lib_32bit_path;
   else
     return NULL;

   /* Some nice comment.  */
   if (optionp("mips4"))
     {
       /* Some more nice comments, explaining.  */
       if (optionp("pg"))
         return xprintf ("%s/gcrt1.o %s/libprof1.a",
                         lib_path, lib_path);

       /* More beautiful, non crytic, comments.  */
       if (optionp("p"))
         return xprintf ("%s/mcrt1.o %s/libprof1.a",
                         lib_path, lib_path);
       else
         etc etc
     }
}

#define STARTFILE_SPEC \
   "%{!shared: \
      %{mabi=n32: \
        %{mips4:%{pg:/usr/lib32/mips4/gcrt1.o%s} \
          %{!pg:%{p:/usr/lib32/mips4/mcrt1.o%s 
/usr/lib32/mips4/libprof1.a%s} \
            %{!p:/usr/lib32/mips4/crt1.o%s}}} \
        %{!mips4:%{pg:/usr/lib32/mips3/gcrt1.o%s} \
          %{!pg:%{p:/usr/lib32/mips3/mcrt1.o%s 
/usr/lib32/mips3/libprof1.a%s} \
            %{!p:/usr/lib32/mips3/crt1.o%s}}}} \
      %{mabi=64: \
        %{mips4:%{pg:/usr/lib64/mips4/gcrt1.o} \
          %{!pg:%{p:/usr/lib64/mips4/mcrt1.o 
/usr/lib64/mips4/libprof1.a} \
            %{!p:/usr/lib64/mips4/crt1.o}}} \
        %{!mips4:%{pg:/usr/lib64/mips3/gcrt1.o} \
          %{!pg:%{p:/usr/lib64/mips3/mcrt1.o 
/usr/lib64/mips3/libprof1.a} \
            %{!p:/usr/lib64/mips3/crt1.o}}}} \

cheers

--
Aldy Hernandez                                E-mail: aldyh@redhat.com
Professional Gypsy Lost in Australia
Red Hat, Inc.