On Wed, Jun 9, 2021 at 12:53 PM Richard Biener
<richard.guent...@gmail.com> wrote:
>
> On Tue, Jun 8, 2021 at 10:45 PM Bill Schmidt <wschm...@linux.ibm.com> wrote:
> >
> > On 6/7/21 12:48 PM, Bill Schmidt wrote:
> > > On 6/7/21 12:45 PM, Richard Biener wrote:
> > >> On Mon, Jun 7, 2021 at 5:38 PM Bill Schmidt <wschm...@linux.ibm.com>
> > >> wrote:
> > >>> On 6/7/21 8:36 AM, Richard Biener wrote:
> > >>>> Some maybe obvious issue - what about DOS-style path hosts?
> > >>>> You seem to build ../ strings to point to parent dirs... I'm not sure
> > >>>> what we do elsewhere - I suppose we arrange for appropriate
> > >>>> -I command line arguments?
> > >>>>
> > >>> Well, actually it's just using "./" to identify the build directory,
> > >>> though I see what you mean about potential Linux bias. There is
> > >>> precedent for this syntax identifying the build directory in config.gcc
> > >>> for target macro files:
> > >>>
> > >>> # tm_file A list of target macro files, if different from
> > >>> # "$cpu_type/$cpu_type.h". Usually it's
> > >>> constructed
> > >>> # per target in a way like this:
> > >>> # tm_file="${tm_file} dbxelf.h elfos.h
> > >>> ${cpu_type.h}/elf.h"
> > >>> # Note that the preferred order is:
> > >>> # - specific target header
> > >>> "${cpu_type}/${cpu_type.h}"
> > >>> # - generic headers like dbxelf.h elfos.h, etc.
> > >>> # - specializing target headers like
> > >>> ${cpu_type.h}/elf.h
> > >>> # This helps to keep OS specific stuff out of
> > >>> the CPU
> > >>> # defining header ${cpu_type}/${cpu_type.h}.
> > >>> #
> > >>> # It is possible to include
> > >>> automatically-generated
> > >>> # build-directory files by prefixing them with
> > >>> "./".
> > >>> # All other files should relative to
> > >>> $srcdir/config.
> > >>>
> > >>> ...so I thought I would try to be consistent with this change. In patch
> > >>> 0025 I use this as follows:
> > >>>
> > >>> --- a/gcc/config.gcc
> > >>> +++ b/gcc/config.gcc
> > >>> @@ -491,6 +491,7 @@ powerpc*-*-*)
> > >>> extra_options="${extra_options} g.opt fused-madd.opt
> > >>> rs6000/rs6000-tables.opt"
> > >>> target_gtfiles="$target_gtfiles
> > >>> \$(srcdir)/config/rs6000/rs6000-logue.c
> > >>> \$(srcdir)/config/rs6000/rs6000-call.c"
> > >>> target_gtfiles="$target_gtfiles
> > >>> \$(srcdir)/config/rs6000/rs6000-pcrel-opt.c"
> > >>> + target_gtfiles="$target_gtfiles ./rs6000-builtins.h"
> > >>> ;;
> > >>> pru-*-*)
> > >>> cpu_type=pru
> > >>>
> > >>> I'm open to trying to do something different if you think that's
> > >>> appropriate.
> > >> Well, I'm not sure whether/how to resolve this. You could try
> > >> building a cross to powerpc-linux from a x86_64-mingw host ...
> > >> maybe there's one on the CF? Or some of your fellow RedHat
> > >> people have access to mingw or the like envs to try whether it
> > >> just works with your change ...
> > >>
> > >> Otherwise it looks OK.
> > >
> > > I'll see what I can find. Thanks again for reviewing the patch!
> >
> >
> > Hm. Ultimately, I think the cross compiler case is doomed unless mingw
> > already handles converting forward slashes to back slashes. There's no
> > single syntax that works on both Windows and Linux. (There's no mingw
> > server in the compile farm to play with.)
> >
> > I'm inclined to accept both "./" and ".\" for native builds, and kick
> > the can down the road beyond that. What do you think?
>
> Can't you use PATH_SEPARATOR somehow? See file-find.c / incpath.c
> or gcc.c for uses and system.h for where it is defined.
Err - DIR_SEPARATOR of course.
Richard.
> Richard.
>
> >
> > Bill
> >
> > >
> > > Bill
> > >
> > >
> > >>
> > >> Richard.
> > >>
> > >>> Thanks for your help with this!
> > >>>
> > >>> Bill
> > >>>
