The onion truck strikes again ... Announcing rake

That would IMHO be a great improvement over imake, although I’m perhaps not
objective because I hate unravelling imake macros (or any other macros, for
that matter).

The basic concepts behind imake are basically sound (very broadly, marrying a
higher level build specification file with site specific configuration to
produce the actual build instructions). However every implementation I’ve
seen that uses imake (about half a dozen, including X) has become so complex
as to be a maintenance headache. So some careful up front thought is
indicated.

Having several people code up alternative prototype implementations is great.
After that, however, we should pause and try to get a consensus on the most
generally applicable and developer friendly ways to implement such a thing.

···

On Friday 14 March 2003 11:29 pm, Gennady wrote:

On Friday, March 14, 2003, at 08:06 PM, Seth Kurtzberg wrote:

A couple of comments.

  1. I hate having to type Makefile instead of makefile. make will
    accept
    either, so any make replacement should allow the initial lower case
    letter.
    Why anyone uses Makefile instead of makefile I’ve never understood…

The convention is that ‘Makefile’ is generated and ‘makefile’ is hand
written. ‘Makefile’ take precedence over ‘makefile’, so if you generate
‘Makefile’ from ‘makefile’ and run make again, everything works as
expected.

Actually, we base our build system on imake (quite different from X
environment, though) and gnumake, so in ‘makefile’ the code is invoked
to generate ‘Makefile’ from ‘Imakefile’ (via include directive and a
build rule Imakefile → Makefile). However recently I started thinking
about replacing imake with ruby. I like Jim’s syntax, however it seems
to me that better way would be to marry rake and gnumake, where ruby is
used to generate Makefile from Rakefile. I’ll give it a shot next week.

Gennady.


Seth Kurtzberg
M. I. S. Corp.
480-661-1849
seth@cql.com

Gennady wrote:

The convention is that ‘Makefile’ is generated and ‘makefile’ is hand
written. ‘Makefile’ take precedence over ‘makefile’, so if you generate
‘Makefile’ from ‘makefile’ and run make again, everything works as
expected.

I’ve been told that it’s the other way around, with ‘makefile’ taking
precedence over ‘Makefile’, and in fact that’s the way it works on
Alpha OSF1 v5.1, for what that’s worth.

I’ve seen ‘Makefile’ hand-written and I’ve seen it generated. I’ve
never heard of a convention either way, but obviously, other people
have.

I’ve only seen ‘makefile’ used once, and that was to override an
unpopular ‘Makefile’.

Differentiating ‘makefile’ and ‘Makefile’ is fine until you have to
port to Windows and case no longer matters…

Louis Krupp

Hey! That’s the reason I always use Makefile instead of makefile!

I never heard the of the handwritten/Generated convention however.

···

On Sat, 2003-03-15 at 02:44, Steve Coltrin wrote:

Seth Kurtzberg seth@cql.com writes:

Why anyone uses Makefile instead of makefile I’ve never understood…

So ls puts it out of the way in the upper left corner, rather than sticking
it in the middle of what you were actually interested in.


– Jim Weirich jweirich@one.net http://w3.one.net/~jweirich

“Beware of bugs in the above code; I have only proved it correct,
not tried it.” – Donald Knuth (in a memo to Peter van Emde Boas)

A couple of comments.

  1. I hate having to type Makefile instead of makefile. make will accept
    either, so any make replacement should allow the initial lower case
    letter. Why anyone uses Makefile instead of makefile I’ve never
    understood…

Easy to do. Ok.

  1. Automatic dependency checking (not just timestamps, but automatically
    discovering dependencies like “make depend”) is important.

I see this functionality as an add-in library. I already have a stand
alone program (called jdepend.rb) which determines the dependencies in a
Java project. I can see reworking the jdepend code so that it can be
used as a library and then in your Rakefile have …

require 'jdepend'
JDepend.generate_java_dependencies

or something like that. Since a Rakefile is really Ruby code, its
trivial to extend it in ways that are difficult in a Makefile.

True, but there are also disadvantages to that approach. Specifically, either
you are using code in the makefile to generate itself (as in appending
additional dependency rules), or you use a second file to hold additional
dependencies. Both are undesirable.

  1. How about implementing something like the clearcase concept of
    derived objects?

Enlighten me. Is that like knowing that X.class is derived from X.java?

No, it is a much more general concept. Clearcase (which by the way has many
disadvantages so I am being selective about its features, not describing it)
is both a version control system and a build system. As such, it is able to
keep track of all build dependencies. For example, when something is linked,
clearcase knows the dependency information for each object file. Thus you
can tell it to link something and from that the requirements for rebuilding
objects can be deduced. These object files are “derived objects”. In the
simple case where an object depends on one or more source files, you can do
this reasonably well with timestamp based dependencies. However, when the
relationships become more complex, complete dependency tracking using only
timestamps becomes untenable.

This is overkill, really, but I think there is much to be gained from looking
at what happens within clearcase and selectively using those features that
can be implemented at a reasonable cost.

The dependency information is also used to automatically generate optimal
parallel build scripts.

···

On Saturday 15 March 2003 01:33 am, Jim Weirich wrote:

On Fri, 2003-03-14 at 23:06, Seth Kurtzberg wrote:


Seth Kurtzberg
M. I. S. Corp.
480-661-1849
seth@cql.com

I’ve done both with Makefiles, but that’s not what I am suggesting.
Consider the following code (which could be placed directly in a
Rakefile)…

Dir['src/**/*.java'].each do |srcfile|
  classfile = srcfile.sub(/^src/, 'classes').sub(/\.java$/, 'class')
  file srcfile
  file classfile => [srcfile] + dependencies_for(classfile) do |t|
    sys %{javac -classpath classes -sourcepath src #{t.name}}
  end
end

That code directly recreates the dependencies without generating the
text of the Rakefile. It would be run afresh every time a Rakefile is
loaded. Of course, calculating dependencies could be a time consuming
operations, so perhaps you wouldn’t want to do it this way … but you
could (very easily).

I think there are some very interesting possibilities here.

···

On Sat, 2003-03-15 at 04:09, Seth Kurtzberg wrote:

I see this functionality as an add-in library. I already have a stand
alone program (called jdepend.rb) which determines the dependencies in a
Java project. I can see reworking the jdepend code so that it can be
used as a library and then in your Rakefile have …

require 'jdepend'
JDepend.generate_java_dependencies

or something like that. Since a Rakefile is really Ruby code, its
trivial to extend it in ways that are difficult in a Makefile.

True, but there are also disadvantages to that approach. Specifically, either
you are using code in the makefile to generate itself (as in appending
additional dependency rules), or you use a second file to hold additional
dependencies. Both are undesirable.


– Jim Weirich jweirich@one.net http://w3.one.net/~jweirich

“Beware of bugs in the above code; I have only proved it correct,
not tried it.” – Donald Knuth (in a memo to Peter van Emde Boas)