[Simh] Here comes a new Makefile - please try it and enhance it!

[Philipp Hachtmann]

Hi again,

>> Sorry to chime in here on things I don't exactly understand...
>> but perhaps that's the point! I took a look at the existing
>> 3.8-0 makefile, and I CAN understand it, yet I don't
>> understand this new makefile.

You can understand the head of the old makefile? I don't.

> There's no rule that a good Makefile is hard to read.
That's correct. I focus on clarity in the definitions of sources and 
options.
The automatic rule expansion at the bottom is a bit more complicated. 
But still not "unreadable" - it is made of a template in the GNU make
documentation.

>> Another thing is SimH needs to be compilable on practically
>> any modern platform, with as few deviations (IFEQ etc) as
>> possible, and with NO changes to the base source code.
>> Doing fancy stuff is asking for problems,
Where is the fancy stuff? Everything is quite straightforward.

> A correct Makefile isn't 'fancy stuff'. It does not impact  
> portability, nor is it any harder to customise than an incorrect  
> Makefile.
> In fact, it is often *helpful* in organising portable software.
:-)
> 
>> and requires
>> extensive testing to make sure it works on ALL platforms.
>> What about a mainframe using who-knows-what version of UNIX?
If there's a GNU make, the makefile WILL simply work.

> It is likely that GNU make will be required, since it's hard to write  
> a good and simple Makefile without its sensible extensions and fixes.  
> GNU make is bundled with OS X, Linux, *BSD, Solaris, Cygwin, mingw...
Yes, the Makefile is for GNU make. I could imagine that one could 
provide the old makefile for compatibility with other makes.

>> I want to keep an open mind, so exactly what are the
>> advantages of this new makefile over the present one?
This Makefile builds each program in the manner of compiling its modules
into object files and then linking together the modules.
With the old Makefile, there are no intermediate object files, leading 
to the fact that if for example scp.c changes, everything has to be 
rebuilt. That's time consuming and annoying.
With the new Makefile, only the object files that are out of date are 
rebuilt, and then make automatically rebuilds the affected applications.
That's not magic, that's simply the correct use case for make.

In the end, you will have a speed gain in compilation time. When I have
solved the problem with pdp10/11 mixed compile and link, I will compare
the build/update times.

An example:

myprog: main.o sun.o moon.o star.o
	gcc -o $@ $(LDFLAGS) $^

%.o : %.c *.h
	gcc -c -o $@ $(CFLAGS) $<

That would help for a simple application. Could be used for SIMH, too.
My makefile does exactly this, except that it uses a template mechanism 
to generate the actual rules. Writing down all the rules would result in 
tons of unused redundant code.

I wonder why my proposals are always rejected....


>>> # Here comes the weird generic stuff. Should be altered
>>> VERY carefully only.
>> ???? this is what I'm talking about. In the existing makefile
>> I can quickly find what needs changing (if anything) and just
>> do it, care (or even much understanding) is not required.

If the weird stuff is done, you WON'T ever have to change it.
Everything simulator related is defined above.

>>> # Add the executable to the CLEANSTUFF list
>>>
>>> CLEANSTUFF+=$$(TARGET_DIR)/$$($(1)_EXEC)$$(EXEC_SUFFIX)
>> ???? a make clean is supposed to remove the extra objects,
>> NOT the EXE's, those are the things I want to keep :-)
> 
> 'clean' conventionally removes derived files including EXEs. If you  
> want to keep them, don't 'clean'; with a correct Makefile (as opposed  
> to recursive hackery) you should rarely, if ever, need to 'clean'.
That's it: clean means clean. You could put your binaries to another 
location
by means of an install rule. But clean will cleanup. That's quite normal
behaviour.

Best wishes,

Philipp