2017-10-22

I am a firm believer that the tool a man uses to should conform to the man not the other way around. If, for example, I need to remove a Phillips-head screw I will not take a slotted screwdriver and forge it into a Phillips-head screwdriver. I will take a Phillips-head screwdriver and use that. In other words I will use a tool that is conformed to the me and my current need rather than adapting myself and fighting with the tool and turning a slotted screwdriver into a Phillips-head and so forth.

Up until this point I have been using an IDE (Integrated Development Environment) for most of my programming. I have tried most of them over the years, but lately I have been using Eclipse and NetBeans. I switched to NetBeans from Eclipse because I got tired of trying to keep track of the consoles. It seems that Eclipse would dump process output to whatever console window it wanted. No amount of chicken-waving would make it stop. So I switched to NetBeans. NetBeans was doing an OK job up until recently when I decided that I want it to span both of my monitors – open files on one monitor and everything else on another monitor. That did not go as well as I had hoped. It would randomly decide to open files on the “other” monitor. I would then drag stuff to the editing monitor. Then open another file. Sometimes it would open on the right monitor, but randomly would open on the wrong monitor. So then I would drag the file over. I decided that I didn’t like that and that it was time to part ways with the IDEs and move to a stand-alone editor.

By dispatching the IDE I was now in need of a way to a build system since all that magic was usually handled by the IDE. So I went looking for a tool and discovered that I did not like any that were available.

autotools

No. Just no.

Make/GNUMake

The grand-daddies of that particular world and it shows. In my humble opinion, no way is this acceptable in the 2nd decade of the 21st century:

%.o : %.c @$(MAKEDEPEND); \ cp $*.Td $*.d; \ sed -e 's/#.*//' -e 's/^[^:]*: *//' -e 's/ *\\$$//' \ -e '/^$$/ d' -e 's/$$/ :/' < $*.Td >> $*.d; \ rm -f $*.Td $(COMPILE.c) -o $@ $< include $(wildcard $(SRCS:.c=.d)

I realize that these tools were created when an interface to a computer was done via a typewriter and in order to produce a single character the typewriter had to be hand-cranked, but c’mon. Maybe I’m just not smart enough to use them; I spend a few hours trying before giving up.

CMake

Looked promising. Generates a Makefile as output. I passed on it because it’s yet another scripting/programming language. I tried the GUI, but that failed with a generic and unhelpful message.

SCons

I used SCons for an EMR project I was working on a thousand years ago. My clearest recollection of it was trying to understand the under the hood workings and running into, what my understanding is, the ‘Python Way’ of doing things. Specifically instance methods and variables being added to classes everywhere and anywhere in the code. So if you wanted to know what a particular instance variable did you’d have to go hunting through the whole code base looking for who, what, where, and when it was inserted into a class.

QMake

I like QMake for Qt projects, but it was a dependency that I did not want to introduce.

Bakefile

Bakefile (http://bakefile.org/) came the closest, but I didn’t like the fact that it has its own configuration language.

 

 

What’s a fella to do. Why roll his own of course. So I did.

My Makefile maker:

• Single file Python script
• No external dependencies
• Configuration is done using standard Python – no new languages/syntax to learn
• Minimal guessing on the part of the script

It is available here: https://github.com/vic-simkus/vics-compilething