Re: [RFC] time for makecc?

[Greg Chicares]

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?

> And make -p (print the rule database) does not help, as its a tangled mess
> of funky s**t---many little twisty passages, all different.

I often find 'make -d' more helpful. It shows the path 'make'
follows through those twisty passages, and tells the reason
for each step.

> So, i propose to create a Makefile compiler,

A translator from a 'complex' makefile to a 'simple' makefile?

> which will create simpler makefiles
> with following properties from the base complex version:
> 
>         - no implicit rules
>         - no patterns
>         - no eval/call constructs
>         - everything else is left intact
>         - all of the expansions in the resulting makefile have to be made 
> in-place

Wouldn't such a compiler have to be as complex as '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.

> 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?