[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pcc-list
Subject:    Re: pcc build system
From:       Iain Hibbert <plunky () rya-online ! net>
Date:       2011-11-03 10:29:11
Message-ID: alpine.NEB.2.00.1111030946480.19062 () galant ! ukfsn ! org
[Download RAW message or body]

On Wed, 2 Nov 2011, LHB wrote:

> 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
[prev in list] [next in list] [prev in thread] [next in thread]