Re: [RFC] time for makecc?

[Samium Gromoff]

At Fri, 06 Feb 2004 12:31:05 -0500,
Greg Chicares wrote:
> Samium Gromoff wrote:
> > 
> > Make does expand implicit rules, patterns, $(eval $(call)) constructs, etc.
> > 
> > In the end the whole thing become somewhat undeterministic as far as human
> > perception goes.
> 
> Difficult-to-understand code can be written in any language.
> Writing clear code is an art. One way to deal with the problem
> is to avoid constructs thought confusing. For instance, many C
> programmers suggest avoiding macros. Could you not avoid
> constructs that you consider likely to cause confusion?
[snip]
> Wouldn't such a compiler have to be as complex as 'make' itself?

I can`t say for sure, but my vague suspicion is that all of the required
information is produced routinely durin the usual make runs.

I.e. i tend to think that makecc could share about 90% of its code with
make itself.

> > I do realise that the resulting makefile will be strictly bound to the 
> > existing
> > file set present in the file tree at the time of compilation -- and that is
> > perfectly ok, for we still have the makefile source and can recompile.
>
> 'automake' may fulfill some of your requirements. At least it
> seems to emit simple makefiles.

I consider automake being a huge PITA which adds more problems than solves.
And yeah i`ve spent enough time to reassure in that opinion.

(Note that i am not opposed towards autoconf/autotools, it`s just automake)

> > P.S. The initial reason i`ve got thinking in this direction is a critical 
> > make bug in
> > the current release. This bug is fixed in the latest unstable debian make 
> > release,
> > but may other distributions suffer from that. And yeah, i`ve got hit by it, 
> > because
> > my code used the buggy $(eval $(call )) feature. Hence i wanted a way to 
> > have a
> > larger makefile which a) is generated from the complex version b) does 
> > exactly the
> > same thing c) is primitive enough that it works :-)
> 
> Would it be easier to fix that defect, say by applying the
> corrective patch you mention, than to create the proposed
> new program, which might perhaps have new defects of its own?

I think that this makecc thing would have many positive sides besides "just 
doing
the thing i need"---for example the most obvious benefit is that the whole
mechanism suddenly becomes much more translucent and people who debug their 
makefiles
will surely benefit from that. Second major point is that the resulting makefile
is much more portable than then original---and this could be a major benefit in 
some
corner cases.

Overall i think this gives the end user more control at zero price. And this is 
always good.

regards, Samium Gromoff