On 6/9/21 5:54 AM, Richard Biener wrote:
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.
Ah -- following the breadcrumbs a little further, it appears that
IS_DIR_SEPARATOR is the proper way to handle both Linux- and
Windows-style syntax. Thanks for the pointer! That should work. Will test.
Bill
Richard.
Richard.
Bill
Bill
Richard.
Thanks for your help with this!
Bill
