Post by Iain HibbertPost by Antoine LecaBut as a general rule, compatibility is pretty good.
we should try to keep the pcc Makefile.in files compatible where possible.
I agree with the goal (of course).
I also believe that, for what matters to (n)make, there is no problem.
Post by Iain HibbertI simplified them somewhat a while ago to explicitly list files, changed
most ${} to $() for example and I don't think VPATH is required anymore,
I also think VPATH is not required (recently built pcc with a bare-bones
make, no problem noticed.) Thanks to standardize at $(), I did not
notice but from what I saw this morning, it was a good move!
On the other hand, I do not see how to save the basic problems related
to shell differences and the lack of sed...
Post by Iain HibbertIt might be easier to find a
make that has compatible syntax which can be built (by pcc) on windows
rather than using one that comes with a commercial development system?
In my experience, developers on Windows do not argue when asked to use
GNU make if there are deficiencies with their native tool: it is pretty
easy to get, and works pretty well on Windows (which is not that usual
with GNU tools on Windows, so kudos to that team.)
On the other hand, I do not believe this is required for PCC when nmake
is already available: it won't bring anything not already available, and
won't solve any of the remaining problem. AFAIK, that is.
Post by Iain HibbertPost by Antoine LecaHowever, a real limit of C99 code when it comes to Windows, is the lack
of support for some C99 features in the C runtime library, and most
notably the %zu printf modifier. And of course, having a C99 compiler is
of no help if the library is still at C89 level.
which is the C runtime library?
(If I wasn't clear enough: I meant libc.)
For many Win32 compilers, it is provided (as a DLL) by the operating
system; it is called MSVCRT.DLL (a hint it is developed by Microsoft
Visual C++ team, known to NOT be very concerned by C99 compatibility).
In fact, the very point of MinGW was to provide the necessary lib*.a and
crt*.o to be able to use (and build) GCC on Win32 using that DLL.
Post by Iain HibbertI didn't think windows came with anything
like that in any case.. If I recall, mip/compat.c provides a basic
printf() that should be sufficient to compile pcc itself (if not, then
lets fix it up :)
Well, if you believe this is a goal, I can investigate a patch to drop
the few remaining places where C99 library features are required; I saw
recently they are mainly in mkext.c, which is anyway a problem in
itself, since when you are building a cross-compiler, the autoconf
HAVE_C99_PRINTF test is by-passed; IMHO, mkext.c (or any locally-run
helper program) should not depend on any feature-test, there are too
much possibilities for confusion between host-available and
build-available features anyway.
Besides long long (which is of course required, but OTOH is present in
all half-decent compilers for more than 13 years now), I do not believe
there are other C99 features required for PCC. Perhaps stdint.h, but
this is so easy to solve at developer's side that it should not matter.
Post by Iain HibbertI think ultimately that although eg Cygwin is available and this can be
used to bootstrap pcc on windows, the point of Cygwin is to provide a
POSIX environment, and just because somebody wants a compiler on Windows,
they don't necessarily want a POSIX environment.. (also, it already
provides a compiler)
Yes.
And while I usually use Cygwin or Interix, I ended considering that the
build.bat approach, with the paths for yacc/bison and flex to be
provided externally, was a very acceptable way to deal with the problem
particularly for a small package such as pcc. (If he still reads,
perhaps Rick can comment on this, I would welcome his point of view.)
On the other hand, the idea to use nmake is very seducing, and when one
tries to actually make use of the Makefile, I believe they are pretty
much usable as they stand... once the @foobar@ stuff is replaced!
Particularly for the building phase, since the installing phase could be
a bit more complex, due to install not existing (we would need some
install.cmd, certainly not impossible), or differences in the directory
structure, even differences between the way to just install programs
(comparing sudo with required-elevation-because-of-UAC.)
However, as you said above, about configure things are very different.
Antoine