pcc build system

[LHB]

I created a new build system for PCC. It has only one Makefile, and it
seems to work. It doesn't build the fortran, and it doesn't support
building in separate directories yet, but I've attached the Makefile.in
and I don't think adding those features would be anything but systematic.

The change was motivated by the musl libc Makefile, which I also attach
for you admiration. I was impressed with it.

Actually, the build uses 4 files:
Makefile.in -- contains what and how to build
global.mk.in -- contains default (from configure) make option values
configure.ac -- gets info about the build system
config_pcc.guess -- 'cooks' host and target triplet into pcc form

I'd gladly put these out in a separate mailing, but any more than 2
attachments would be impolite.

What do y'all think?

[Thorsten Glaser]

I created a new build system for PCC. It has only one Makefile, and it seems

No, it uses a GNUmakefile, not a Makefile. I absolutely veto this,
and I’m sure I’m not alone with that.

bye,
//mirabilos, who’d rather see it use <bsd.prog.mk> which is portable enough

[Steve Kargl]

Post by Thorsten Glaser

I created a new build system for PCC. It has only one Makefile, and it seems

No, it uses a GNUmakefile, not a Makefile. I absolutely veto this,
and I???m sure I???m not alone with that.

+1

[LHB]

Post by Thorsten Glaser

I created a new build system for PCC. It has only one Makefile, and it seems

No, it uses a GNUmakefile, not a Makefile. I absolutely veto this,
and I???m sure I???m not alone with that.

It seems silly to buy into Gnu Autoconf but reject Gnu Make, especially
when faced with the challenge of creating something that will run on so
many different systems.

Even after 20 minutes of searching I was unable to find decent
documentation for any other 'make' in all of googledom. Even Apple uses
gnu make.

If you look up Make on wikipedia, only one Make has decent
documentation, Gnu Make. FreeBSD only has a manpage. and the Open Group
Make specification lists requirements, but hardly counts as a manual.

If anybody can point me to a manual on some other widely used version of
make I will gladly read it and try to adjust things to your liking.

+1

[Steve Kargl]

Post by LHB
If you look up Make on wikipedia, only one Make has decent
documentation, Gnu Make. FreeBSD only has a manpage. and the Open Group
Make specification lists requirements, but hardly counts as a manual.

Did you bother to look at the FreeBSD manpage? See
the FILE section that points at the pmake tutorial.
Try a google search with 'pmake tutorial'.

[LHB]

Post by Steve Kargl

Post by LHB
If you look up Make on wikipedia, only one Make has decent
documentation, Gnu Make. FreeBSD only has a manpage. and the Open Group
Make specification lists requirements, but hardly counts as a manual.

Did you bother to look at the FreeBSD manpage? See
the FILE section that points at the pmake tutorial.
Try a google search with 'pmake tutorial'.

OK. I did. And what I garner is that gnu make and bsd make (pmake) are
pretty much the same thing except for notation. Would people be happier
if notation were changed to bsd notation?

The reason Gnu, BSD and Opus (I checked them out) all have the same
functionality* is because maintaining sophisticated builds requires it.

I can install pmake on my system and change the Makefile.in to BSD style
, and seems eminently more sensible than going back to Makefile
standards circa 1976 . I have no dog in the BSD vs. Gnu fight.

That's my take.


*shell output capture, wildcards, text substition, extracting
directory/base names)

[Iain Hibbert]

It seems silly to buy into Gnu Autoconf but reject Gnu Make, especially when
faced with the challenge of creating something that will run on so many
different systems.

The problem with this would be that GNU autoconf is only required for
somebody changing the configuration settings, not for configuring the
build.. I think the configure script only uses POSIX tools, so it can
be used on most any system?

Also, don't hardcode program names, like ar and rm, in Makefile
commands: macroize them, and their arguments, instead.

I think the GNU autoconf system doesn't have macros for such basic
commands, as they are considered POSIX and should be present on all
systems that have a /bin/sh

Even after 20 minutes of searching I was unable to find decent documentation
for any other 'make' in all of googledom. Even Apple uses gnu make.

to start with, the NetBSD make is documented extensively here

http://netbsd.gw.com/cgi-bin/man-cgi?make++NetBSD-current

and I don't know how different the other BSD makes are these days, but I
would not recommend using any extended features in any case..

If you look up Make on wikipedia, only one Make has decent documentation, Gnu
Make. FreeBSD only has a manpage. and the Open Group Make specification lists
requirements, but hardly counts as a manual.

As those are the minimum requirements, they are really the maximum
requirements that we should use to cause the least problems building on a
wide variety of systems.

The problem with using GNU make is that it is not bundled with the pcc
sources, and is not necessarily installed on a supported platform. That it
could be is not a good excuse, imo..

I'm not sure that many people think GNU autoconf is the best possible tool
to use here, but it works and nobody has come up with an alternative as
yet.

iain

[LHB]

OK. The reaction has been interesting. One person from Utah did give me
contructive criticism and I do appreciate it.

I was thinking of another thing to try, to help with the many options
that need to be parsed. I was thinking that maybe lex/yacc could be
used to process the command line options on the main pcc program. Their
are so many options, and the command line does operate like a state
machine, maybe flex/yacc would help organize it and make it easier to
improve and embellish.

[Thorsten Glaser]

Post by Iain Hibbert

It seems silly to buy into Gnu Autoconf but reject Gnu Make, especially when
faced with the challenge of creating something that will run on so many
different systems.

autoconf runs on the developer's system, gmake on the system of the
person actually building it. So huge difference. (And personally,
I’d rather not need autoconf either, just its replacements are all,
no exception, even worse, and "better the hell you know", which also
makes the job easier for our packagers.)

Post by Iain Hibbert
build.. I think the configure script only uses POSIX tools, so it can
be used on most any system?

Even less than POSIX; the autoconf documentation has an extensive
part about Portable Shell Scripting.

Post by Iain Hibbert
and I don't know how different the other BSD makes are these days, but I

https://www.mirbsd.org/man1/make

Differs slightly from OpenBSE, but only slightly.

Post by Iain Hibbert
would not recommend using any extended features in any case..

Yes. My desire to push BSD make is actually just that, a desire.
We should stick to portable make. Maybe use GNU automake, which
generates those, but not if we can avoid it please.

bye,
//mirabilos

[Antoine Leca]

Post by LHB
Even after 20 minutes of searching I was unable to find decent
documentation for any other 'make' in all of googledom.

Then it means all of POSIX, SUS, OpenSolaris, and *BSD, have been
finally put out from Googledom. I find it a pity, but it should be the
price to pay for the progress of Open Source, I guess.

Then I has a question : if GNU make and GNU autotools are now the
Standard, what is the point to try to develop another compiler?

Post by LHB
Even Apple uses gnu make.

Last time I checked, Apple was an industrial company. Setting up
standards for basic tools such as make are something companies do
eventually; and enforcing its own standards is something you ought to
expect from them; you can even find people which will see it as a sign
of good management.

Post by LHB
If you look up Make on wikipedia, only one Make has decent
documentation, Gnu Make.

I am impressed by the work done by some GNU zealots^W fans to portrait
Gnu tools in wikipedia as the main representative of the OpenSource or
Unix toolsets. Yet I did not envision it could be read as if they were
the _only_ representatives.
Furthermore, the English version of the wikipedia page for make makes
pretty clear GNU make is just one of the variants; a quick reading even
showed me that the use of the GNU specific features are tagged as such.
As always with wikipedia, if your native language version does not show
as such, you are invited to improve it. [Note to self: improve the
French version which is pretty bad in this respect.]

Post by LHB
If anybody can point me to a manual on some other widely used version
of make I will gladly read it and try to adjust things to your liking.

You might not like it ;-), but here is one
http://msdn.microsoft.com/en-us/library/dd9y37ha.aspx


Antoine

[Krishna]

Even after 20 minutes of searching I was unable to find decent documentation
for any other 'make' in all of googledom.  Even Apple uses gnu make.
If you look up Make on wikipedia, only one Make has decent documentation,
Gnu Make.  FreeBSD only has a manpage. and the Open Group Make specification
lists requirements, but hardly counts as a manual.
If anybody can point me to a manual on some other widely used version of
make I will gladly read it and try to adjust things to your liking.

[1] http://netbsd.gw.com/cgi-bin/man-cgi?make+1+NetBSD-current --
make(1) from netbsd

[2] http://www.crufty.net/help/sjg/bmake.html -- info on the portable
version of netbsd's make

[LHB]

Post by Krishna

Even after 20 minutes of searching I was unable to find decent documentation
for any other 'make' in all of googledom. Even Apple uses gnu make.
If you look up Make on wikipedia, only one Make has decent documentation,
Gnu Make. FreeBSD only has a manpage. and the Open Group Make specification
lists requirements, but hardly counts as a manual.
If anybody can point me to a manual on some other widely used version of
make I will gladly read it and try to adjust things to your liking.

[1] http://netbsd.gw.com/cgi-bin/man-cgi?make+1+NetBSD-current --
make(1) from netbsd
[2] http://www.crufty.net/help/sjg/bmake.html -- info on the portable
version of netbsd's make

To somebody just starting out on Makefiles, these are completely
inadaquate. They are readable to me now, AFTER I read the Gnu Make
manual.

A man page is not a manual. I did not learn QFT from a manpage.
Evidently a number of people here think that I should have been able to
do so. Thinking like this strikes me as a bit delusional.

[Iain Hibbert]

Post by LHB
To somebody just starting out on Makefiles, these are completely
inadaquate. They are readable to me now, AFTER I read the Gnu Make
manual.

In truth, the bmake system is a lot easier to write basic makefiles for,
since all you need to do in most cases is list the source files and
include <bsd.prog.mk>. Then, at least with the NetBSD sources (which bmake
comes as part of), there are plenty of examples to copy from.

What is harder with bmake is going into expert mode, and there the
reference manpage is actually very useful (and since you are now an
expert, it doesn't need to be too basic :)

Post by LHB
A man page is not a manual.

Hm, is it a koan?

iain

[Hauke Fath]

Post by LHB

Post by Krishna

Post by LHB
If anybody can point me to a manual on some other widely used version of
make I will gladly read it and try to adjust things to your liking.

[1] http://netbsd.gw.com/cgi-bin/man-cgi?make+1+NetBSD-current --
make(1) from netbsd
[2] http://www.crufty.net/help/sjg/bmake.html -- info on the portable
version of netbsd's make

To somebody just starting out on Makefiles, these are completely
inadaquate. They are readable to me now, AFTER I read the Gnu Make
manual.

The 4.4BSD Programmer's Supplement Documents (PSD) have this:

<http://docs.freebsd.org/44doc/psd/12.make/paper.html>
<http://docs.freebsd.org/44doc/psd/12.make/paper.pdf>

-- it is how I learned BSD make(1).

I don't know how FreeBSD built the PDF, it looks messy in places on Acrobat
Reader 3; but you can rebuild the chapter on any *BSD machine.

HTH,
hauke


(Pity the 4.4BSD URM does not have an introduction on using a web search
engine...)



--
"It's never straight up and down" (DEVO)

[Thorsten Glaser]

Post by Hauke Fath
I don't know how FreeBSD built the PDF, it looks messy in places on Acrobat
Reader 3; but you can rebuild the chapter on any *BSD machine.

There’s https://www.mirbsd.org/manPSD/12.make

//mirabilos

[Hauke Fath]

Post by LHB
It seems silly to buy into Gnu Autoconf but reject Gnu Make, especially
when faced with the challenge of creating something that will run on so
many different systems.

The GNU autotools do not mandate GNU make - unless naive maintainers build
in GNUisms. While there may be a case for hairball complexity projects
(*cough* gcc) to use exotic features of a particular make(1)
implementation, I don't think pcc is at that level.

hauke

--
"It's never straight up and down" (DEVO)

[Nelson H. F. Beebe]

$(INSTALL_PROGRAM) --strip -T $(pcc_BIN) $(DESTDIR)$(bindir)/$(notdir $(pcc_BIN))

The --strip option works only with the GNU version of strip.
Stripping should not be the default, at least at developer sites.
Disk space is cheap, and the amount saved is trivial. The loss of
debuggability is severe.

I suggest moving the --strip option to an INSTALL_PROGRAM_FLAGS option
that can be altered on the command line.

Also, don't hardcode program names, like ar and rm, in Makefile
commands: macroize them, and their arguments, instead.

Rules like

$(pcc_BIN): $(pcc_OBJS)
$(CC) $(LDFLAGS) -o $@ $^ $(LIBS)

MUST include $(CFLAGS) as well: they are sometimes needed by both
compiler and linker (e.g., GNU -m32 and -m64 memory model options).

The syntax

cd $(DESTDIR)$(bindir); rm -f $(notdir $(pcc_BIN))

is decidedly not portable. It uses the $(...) ksh/bash/zsh extension
to /bin/sh, and a nonstandard program notdir. Please stick to
portable /bin/sh constructions, and use the test command to
distinguish between files and directories.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: [phone] -
- University of Utah FAX: [phone] -
- Department of Mathematics, 110 LCB Internet e-mail: ***@math.utah.edu -
- 155 S 1400 E RM 233 ***@acm.org ***@computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------

[Thorsten Glaser]

Post by Nelson H. F. Beebe
The syntax
cd $(DESTDIR)$(bindir); rm -f $(notdir $(pcc_BIN))
is decidedly not portable. It uses the $(...) ksh/bash/zsh extension
to /bin/sh, and a nonstandard program notdir. Please stick to

I agree with you on the other counts but feel I must correct you
here, twice.

First off, $(...) is POSIX Shell and has replaced U+0060 entirely,
except in pre-POSIX Bourne Shells.

Second, his syntax is actually GNU make – using $(...) in make
would look like $$(...) due to the variable expansion make does.

bye,
//mirabilos

[LHB]

Post by Nelson H. F. Beebe

$(INSTALL_PROGRAM) --strip -T $(pcc_BIN) $(DESTDIR)$(bindir)/$(notdir $(pcc_BIN))

The --strip option works only with the GNU version of strip.

Yes, that could be changed.

Post by Nelson H. F. Beebe
Stripping should not be the default, at least at developer sites.
Disk space is cheap, and the amount saved is trivial. The loss of
debuggability is severe.

That's a judgement call. Ideally, a person doesn't install to debug
PCC, but to use it. If a person installed with -DPCC_DEBUG then
definitely shouldn't strip. Given that PCC won't even compile without
PCC_DEBUG, the line between the two cases is blurred.

I agree, though, for the time being, probably shouldn't strip.

Post by Nelson H. F. Beebe
Also, don't hardcode program names, like ar and rm, in Makefile
commands: macroize them, and their arguments, instead.

I chose not to do this because there were no AC_ macros to check for
them and I didn't want to give the incorrect impression that these were
variables, when they were not just to impress my friends that I could
turn every command into a macro.

I checked for an AC_PROG_AR macro but there wasn't one, and I didn't
want to cook up some half-baked m4 macro myself. I agree that if such
as macro is available somewhere, then it should be used.

rm -f is used in the current configure.ac script(without a macro), so
the current build system already assumes that this is available.

Post by Nelson H. F. Beebe
MUST include $(CFLAGS) as well: they are sometimes needed by both
compiler and linker (e.g., GNU -m32 and -m64 memory model options).

I did not know this. That's why I sent it out, so people smarter than
me would point these things out. ;-)

Post by Nelson H. F. Beebe
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: [phone] -
- University of Utah FAX: [phone] -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------

[Nelson H. F. Beebe]

Here is how to check for particular programs in autoconf input:

AC_CHECK_PROGS(AWK, mawk nawk gawk bawk awk)
AC_CHECK_PROGS(RM, rm)
AC_CHECK_PROGS(SED, sed)
AC_CHECK_PROGS(SPLINT, [splint lclint])
AC_PATH_PROG(SHELL, sh)

As the first example shows, you can supply a preferred search order
among multiple versions of a tool; the list can be bracketed, as shown
in the fourth example.

Makefiles should always set SHELL, normally to /bin/sh; the last
example shows how to get a full pathname. Most Unix/Linux systems
don't require SHELL to be set in a Makefile, and assume /bin/sh if it
is not set. However, there have been systems that instead defaulted
to the user's login shell, which might be in the csh/tcsh (or other)
families, and not syntax-compatible with /bin/sh, the shell that
should be used for maximal portability of Makefile commands.

I make a strict habit of defining all Makefile program names
indirectly via macro definitions, because no user should ever be
forced to edit a Makefile just to use a different version of a
program. Here's a common example of a command-line override:

make CC=/usr/local/test/bin/pcc

-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: [phone] -
- University of Utah FAX: [phone] -
- Department of Mathematics, 110 LCB Internet e-mail: ***@math.utah.edu -
- 155 S 1400 E RM 233 ***@acm.org ***@computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------

[LHB]

Post by Nelson H. F. Beebe
AC_CHECK_PROGS(AWK, mawk nawk gawk bawk awk)
AC_CHECK_PROGS(RM, rm)
AC_CHECK_PROGS(SED, sed)
AC_CHECK_PROGS(SPLINT, [splint lclint])
AC_PATH_PROG(SHELL, sh)

I'll add, AC_CHECK_PROGS(AR, ar) since it is essential to the build.
If there are other versions of 'ar', I would gladly add them to the list
to check.

Lee

[Michael Shalayeff]

Post by LHB
I created a new build system for PCC. It has only one Makefile, and

why? what is the purpose of this?
what is wrong with current system?
are you doing this just because you can?
well i suppose you've had a fun excercise...
cu

[LHB]

Post by Michael Shalayeff

Post by LHB
I created a new build system for PCC. It has only one Makefile, and

why? what is the purpose of this?
what is wrong with current system?
are you doing this just because you can?

You could say the same about the whole open source movement.

[Michael Shalayeff]

Post by LHB

Post by Michael Shalayeff

Post by LHB
I created a new build system for PCC. It has only one Makefile, and

why? what is the purpose of this?
what is wrong with current system?
are you doing this just because you can?

You could say the same about the whole open source movement.

this generalisation is not gonna do anything either.

but if you are so eager to type than maybe you can just get
rid of autoconf all together instead of depending on it even more...
cu

[Krishna]

Post by Michael Shalayeff

Post by LHB

Post by Michael Shalayeff

I created a new build system for PCC.  It has only one Makefile, and

why? what is the purpose of this?
what is wrong with current system?
are you doing this just because you can?

You could say the same about the whole open source movement.

this generalisation is not gonna do anything either.
but if you are so eager to type than maybe you can just get
rid of autoconf all together...

or replace it with autosetup[1]. Some examples are presented in [2].

[1] http://msteveb.github.com/autosetup/
[2] http://msteveb.github.com/autosetup/developer/examples/

[LHB]

Post by Krishna

Post by Michael Shalayeff

Post by LHB

Post by Michael Shalayeff

Post by LHB
I created a new build system for PCC. It has only one Makefile, and

why? what is the purpose of this?
what is wrong with current system?
are you doing this just because you can?

You could say the same about the whole open source movement.

this generalisation is not gonna do anything either.
but if you are so eager to type than maybe you can just get
rid of autoconf all together...

or replace it with autosetup[1]. Some examples are presented in [2].
[1] http://msteveb.github.com/autosetup/
[2] http://msteveb.github.com/autosetup/developer/examples/

I looked at this. This has a drawback in that autosetup is run on the
users end. They have to have Tcl on their computer, rather than just a
shell. I kinda like the idea though.

Actually, I did figure out a way to completely eliminate autoconf and
the os and arch subdirectories. Simply use patches. Have config.guess
get the canonical build system type and apply a patch for OS and a patch
for CPU and then build. This would also eliminate many of those
horrible horrible ifdef macros in the code. This is more of "git"
method of development, where there is a main line of development with
parallel running branches.

Each os/cpu could have a patch maintainer that fixes any possible conflicts.

From what I have seen, the patches would probably be quite small and
managable.

[Krishna]

Post by Krishna
or replace it with autosetup[1]. Some examples are presented in [2].
[1] http://msteveb.github.com/autosetup/
[2] http://msteveb.github.com/autosetup/developer/examples/

I looked at this. This has a drawback in that autosetup is run on the users
end.

so is ./configure

They have to have Tcl on their computer, rather than just a shell.

no they don't have to; autosetup comes with jimtcl, a lightweight
(single .c+.h file) tcl interpreter which can be used when there is no
standard tcl available. tcl being higher level than shell opens up the
possibility to cover platforms like windows+mingw (I've not done that
yet so not entirely sure).

 I kinda like the idea though.

tcl is nice and quite suitable for things approaching DSLs. m4 macros
OTOH, *sigh*

Actually, I did figure out a way to completely eliminate autoconf and the os
and arch subdirectories.  Simply use patches.  Have config.guess get the
canonical build system type and apply a patch for OS and a patch for CPU and
then build.  This would also eliminate many of those horrible horrible ifdef
macros in the code.

cross-compilers?

Each os/cpu could have a patch maintainer that fixes any possible conflicts.
From what I have seen,  the patches would probably be quite small and
managable.

Not sure. Would love to see some work breaking ifdefs into patches
especially on a tree like boehm-gc.

btw where do these patches live? arch/ and platform/? ;)

I don't think PCC has a build system problem at the moment but thanks
anyway for sharing your Makefile(s) -- picked up a few things there.

/back-to-lurking-mode.

[LHB]

First of all, thank you for your contemplative input, Krishna.

Post by Krishna
no they don't have to; autosetup comes with jimtcl, a lightweight
(single .c+.h file) tcl interpreter which can be used when there is no
standard tcl available. tcl being higher level than shell opens up the
possibility to cover platforms like windows+mingw (I've not done that
yet so not entirely sure).

That is a plus. I am no fan of autoconf. If I change the Makefile,
then I have to remember to change the Makefile.in and otherwise change
Makefile.in then run autoconf, which is slow.

So autosetup would be quicker. But, the whole Makefile.in config.h
concept seems flawed to me, especially after considering the patch idea.
config.h seems to encourage bad behavior. The #ifdef HAVE_XXX_H idiom
is abused in pcc.c . The #ifdef guard implies that something like
<sys/wait.h> is optional, when it is not. A person compiling is better
off getting an error telling them that <sys/wait.h> can't be found,
rather than a compile error around one of the macros, <sys/wait.h> defines.

I had it happen to me. It sucks.

Post by Krishna

Actually, I did figure out a way to completely eliminate autoconf and the os
and arch subdirectories. Simply use patches. Have config.guess get the
canonical build system type and apply a patch for OS and a patch for CPU and
then build. This would also eliminate many of those horrible horrible ifdef
macros in the code.

cross-compilers?

Each os/cpu could have a patch maintainer that fixes any possible conflicts.
From what I have seen, the patches would probably be quite small and
managable.

I don't think PCC has a build system problem at the moment but thanks
anyway for sharing your Makefile(s) -- picked up a few things there.

But it does. Try compiling without PCC_DEBUG. You can't. The current
build system says you can. That is wrong.

Moreover, there is a LOT of redundancy in code. Information redundancy
is just bad computer science, which is why I kinda like the patch idea.
A patch isolates the information that differs and puts it into a human
readable form. In fact, you could make it so the Makefile itself is
patched, so that it will execute under the appropriate make for a
particular OS. That way, you could keep the functionality of a decent
make file without sacrificing portability. I bet that if I created a
Gnu Makefile, somebody on this mailing list could, in less than an hour,
crank out a patch to make it work precisely the same using b/p/make.
then it's just a matter of,

if test./config.guess | grep "bsd"; then
patch Makefile.bsd.diff
fi

Anyhow, that's what I'm thinking.

Post by Krishna
/back-to-lurking-mode.

[Thorsten Glaser]

Post by LHB

Post by Krishna
no they don't have to; autosetup comes with jimtcl, a lightweight

That was actual fun, I spent part of an evening learning about that
now and extending the detection script to include detection code for
jimtcl (and wish)… probably ugly, but I don’t speak Tcl either.
https://www.mirbsd.org/cvs.cgi/contrib/code/Snippets/getshver?rev=HEAD

Post by LHB
So autosetup would be quicker.

Please do not use Yet Another Configure System which first itself
needs to be ported to the system by a packager. While we *all*
agree that GNU autofools is a hell it’s well-known and people by
now know how to deal with it. (Also, the mere idea of having to
host-compile an interpreted language in order to be able to con‐
figure a compiler (gah!) seems sick to me.)

Post by LHB
I bet that if I created a Gnu Makefile, somebody on this mailing list could, in
less than an hour, crank out a patch to make it work precisely the same using
b/p/make. then it's just a matter of,

Oh please. Go away. Shut up and hack.

Post by LHB
if test./config.guess | grep "bsd"; then
patch Makefile.bsd.diff
fi

There’s a lot of different make implementations out there, in practical
use. I got slapped recently because I write ${var} whereas the standard
only supports $(var) as well… Microsoft has a very widely used one, and
the AT&T guys (UWIN, etc.) have, and I think even the Plan 9 crowd does.

So please accept the fact that there’s very strong antipathy against
this idea, no matter how much merit it might seem to have, accept the
learning experience you gained and the other contributions here (like
I did, for my fun Tcl evening), and move on. There’s enough work to do.

This thread has lived long enough.

bye,
//mirabilos

[Iain Hibbert]

But, the whole Makefile.in config.h concept seems flawed to me,
especially after considering the patch idea. config.h seems to encourage
bad behavior. The #ifdef HAVE_XXX_H idiom is abused in pcc.c .

Lets not say anything good about cc.c here, since it is an evolutionary
mess and the whole thing needs to be redesigned from the ground up. Joerg
did provide some ideas for a new driver, but it needs more work to become
useable.. I had some other ideas which I have not explored fully but I
think it should not be too complex (in essence, a code generator for the
host OS to process a simplified descriptor file to create the source to be
built for the target OS -- not sure if native tools are sufficient for
this or if I need to write a specific one)

The #ifdef guard implies that something like <sys/wait.h> is optional,
when it is not. A person compiling is better off getting an error
telling them that <sys/wait.h> can't be found, rather than a compile
error around one of the macros, <sys/wait.h> defines.

This is somewhat true, and I recall that somebody (Joerg, again?)
suggested some time ago that it might be better to just supply a file with
the minimal pieces for when the host OS does not supply it. This is
essentially how the compat functions work, they are used as if they exist
and are built if they do not.

I agree that the <sys/wait.h> thing is actually a mess, since it is only
required I think for the POSIX style systems with waitpid() and
WIFEXITED(); the #ifdef os_win32 exec code doesn't use them. However,
incremental redesigns here seem futile..

I at least would like to remove all the #ifdef os_ stuff from the ccom and
cpp parts, I think all that stuff should be handled by the configure
script or front end passing an option (eg -freg-struct-return rather than
os_openbsd in i386)

But it does. Try compiling without PCC_DEBUG. You can't. The current
build system says you can. That is wrong.

This is a known issue and what to do about it is also known, if not
urgent.

Moreover, there is a LOT of redundancy in code. Information redundancy
is just bad computer science, which is why I kinda like the patch idea.
A patch isolates the information that differs and puts it into a human
readable form.

On the other hand, it becomes difficult to work on the code in several
architectures at the same time if you work with multiple patchsets. (and,
working with patches to patches is not pleasant :)

iain

[LHB]

Post by Michael Shalayeff

Post by LHB

Post by Michael Shalayeff

Post by LHB
I created a new build system for PCC. It has only one Makefile, and

why? what is the purpose of this?
what is wrong with current system?
are you doing this just because you can?

You could say the same about the whole open source movement.

this generalisation is not gonna do anything either.
but if you are so eager to type than maybe you can just get
rid of autoconf all together instead of depending on it even more...
cu

normally I wouldn't respond to something so snide, but I do want to make
clear that my configure.ac file is much smaller than the current one.
In other words, it depends even less on autoconf. Just sayin..

[Janne Johansson]

Post by LHB

Post by Michael Shalayeff

Post by LHB
I created a new build system for PCC. It has only one Makefile, and

why? what is the purpose of this?
what is wrong with current system?
are you doing this just because you can?

You could say the same about the whole open source movement.

You might view this as a thing in general, but at least I view your
proposed version from a PCC perspective in particular.
I've interrested myself in PCC because it is lightweight and still usable.
If I wanted bloat and hours of compiling to get a compiler,
gcc is already there for me. When you propose to make something more
complex, there should be a definite need and purpose to
this decision, which is exactly what Mickey is asking you for. What makes
the added cost of complexity worth everyones while here?

The less stuff pcc depends on, the bigger the chance of it being able to be
bootstrapped and crosscompiled and run on odd systems.
The more autoconf/automake/gmake/libtool/boost/gawk stuff people add, the
less systems will it work on, and finally ending up being
some kind of linux-i386/amd64 only novelty, since that is the only place
where all the combined dependencies will be available.

So if you don't have answers to the questions above, I don't think I will
like your solution-that-looks-for-a-problem.

Still, since it actually is open-source, feel free to fork it off, add
whatever complexities you fancy and see if your version "wins" the hearts
of the masses. I just won't be one of them. Not having answers to basic
questions usually are an indication that the work isn't really
thought through.

[LHB]

Post by Janne Johansson
You might view this as a thing in general, but at least I view your
proposed version from a PCC perspective in particular.
I've interrested myself in PCC because it is lightweight and still
usable. If I wanted bloat and hours of compiling to get a compiler,
gcc is already there for me. When you propose to make something more
complex,

stop right there pardner. 1 file is more complex than multiple files
spread over the directory tree? The reason every single implementation
of make has the features I used, even bsd make, is because it makes
thinks simpler and more maintainable.

http://www.freebsd.org/doc/en/books/pmake/modyvarex.html

Did Adam de Boor go through the time and effort to create the above
functionality because it makes things more complex, or because he
thought it made things simpler?

[Michael Shalayeff]

Post by LHB

Post by Janne Johansson
You might view this as a thing in general, but at least I view your
proposed version from a PCC perspective in particular.
I've interrested myself in PCC because it is lightweight and still
usable. If I wanted bloat and hours of compiling to get a compiler,
gcc is already there for me. When you propose to make something more
complex,

stop right there pardner. 1 file is more complex than multiple
files spread over the directory tree? The reason every single
implementation of make has the features I used, even bsd make, is
because it makes thinks simpler and more maintainable.

one makefiel is not simpler than smaller ones
per directory/project etc.
just imagine handling all archs multiplied by all compilers
(currently only two) and so on.
it simply does not scale
trying to employ all possible features just because they
are there and someone made 'em does not justify it either
cu

[Nelson H. F. Beebe]

if GNU make and GNU autotools are now the Standard,
what is the point to try to develop another compiler?

The point is the extreme dangers of MONOCULTURE, which applies to
biology, human societies, and many areas of computing. If all
software depends on one compiler, and that compiler is not available,
or fails to compile the code, or produces incorrect code, then the
software is dead.

One of the great values of C programming is the diversity of
independent compilers that are available on many platforms. On my 25
or so flavors of Unix in my test lab, I have more than a dozen such
compilers.

Contrast that with the scripting world, where, except for awk with
three free implementations, a commercial fourth, and a marginal fifth,
most scripting languages have only a single implementation. There are
often multiple versions of those implementations, but they are often
for slightly different flavors of the scripting language.

Java is only marginally better in choice of compilers: I keep the
Sun/Oracle, IBM, and GNU compilers on our main systems, so at least
two or three choices are available. Most sites with Java probably
have only a single version.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: [phone] -
- University of Utah FAX: [phone] -
- Department of Mathematics, 110 LCB Internet e-mail: ***@math.utah.edu -
- 155 S 1400 E RM 233 ***@acm.org ***@computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------

[LHB]

Post by Nelson H. F. Beebe

if GNU make and GNU autotools are now the Standard,
what is the point to try to develop another compiler?

The point is the extreme dangers of MONOCULTURE,

I agree. I like the way PCC does things. In particular, I have some
experience with lex and bison and I managed to write an ASN1 parser
translater with them. I was curious to see whether this could be done
with C. Evidently, it can.