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.
Richard.
>
> Bill
>
> >
> > Bill
> >
> >
> >>
> >> Richard.
> >>
> >>> Thanks for your help with this!
> >>>
> >>> Bill
> >>>
