I followed a link Raph mentioned recently to David McCusker's site. I was amazed at the openness with which David shares his personal life and seemingly, intentionally with the general public. Here is a quandary for me. Reading a personal diary evokes a personal response. But I don't David at all (well, apart from what I've read). Are social norms sufficiently different in this context from regular conversational contexts that a response to (hard) personal matters from a stranger would be normal here? The additional, complication is that not everything I would like to say seems appropriate for 'first contact'. More specifically, if a friend were to unburden his heart to me there is an openness in the friendship that allows both comfort and criticism. Can this level of familiarity be forged in a moment? I don't think so and that leads me to say that a response is more likely to come from someone who has an established relationship with David already. But in that case why is everyone told? In any case, having publically aired my confusion, I will say that I hope for the best for all involved without going into what exactly that means.
While refactoring some Quixotic code I obliterated large chunks of working code accidently. Coupled with the increasing need to organize my Makefile into something sensible I attempted a swan dive into the GNU pool. Having crawled out of the pool I now have stinging, red skin from the gigantic belly flop.
More specifically I tried to start a personal CVS repository, conquer the auto* tools and perform experimentation with gcc, gdb and gprof simultaneously. I am slightly confused by what happened. I don't think there are any conceptual barriers to the tools; in fact I'm fairly sure I understand what need each of them addresses. On the other hand, I'm not as surprised as I might make it sound. I've known for a long time why I haven't approached many of the tools - they seem inflexible and inelegant.
That may sound harsh but that's not my intention. I feel the need to explain further but have the dreaded feeling that this is going to come out all wrong. Nonetheless I'll try to give a few examples (which may not be strictly true of the GNU tools but hopefully are generally true of the way they're used -- see I'm qualifying already):
So using Makefiles you can cross-compile to a plethora of platforms, write shell scripts, call any external tools you need and its inflexible?
no structure to create within
The majority of a platforms (to my limited knowledge) which the auto* tools are used on are Unix variants with frustratingly petty differences (my impression, I remain ignorant). It is nice to be isolated from these differences as much as possible. Nicer still would be to fix stupid differences. Shells are not guarenteed but may be entrenched. Bash scripting also has excellently archaic syntax. External tools become dependencies which need to be pre-installed and as such are used only in a restricted manner.
structure to create within is anoying :)
Hardcoded directory format and files. The guts of the build process are always hanging out all over the place. I'd prefer build related files to be somewhere nice like in a directory called build.
- no structure to create within
strange consistency and cyrptic historically evolved techniques (survival of the obscure?)
bin_PROGRAMS = helloThis may be familiar to some and its not a major conceptual barrier - its an annoyance barrier. Why did compound words suddenly appear and taken on special meanining? It just doesn't *feel* right. Configure.in and Makefile.am *seem* like a gigantic bundle of IFs, GOTOs and black boxes (M4 macros).
hello_SOURCES = hello.h hello.cc main.cc
This point could be summarized by saying that using Makefiles isn't an a-ha or clean or fun experience. Its more of 'alright here we go..." manual labour kind of thing.
Hierarchies and relationships appear to be hard to accomplish in a clean manner.
It seems hard to make multiple build pathways (ie. different compilers, or different compiler flags, etc.). It seems harder still to visualize these pathways as time goes on. It appears difficult to chain makefiles together efficiently in, to sub-projects, or out, to connect broader projects together.
Poor means of establishing boundaries and contexts
For instance, I'd like to be able to create a project with sub-projects which might be shared libraries, or loadable modules, or give a name to some aspect of the project which I treat as some kind of unity. More broadly it seems that there is a lack of ability to name things and then refer to things by name.
- strange consistency and cyrptic historically evolved techniques (survival of the obscure?)
While I'm on the soapbox, I'll also take this opportunity to say that it has been my experience that this is a universal problem. Makefile problems seem to be a very common frustration when experimenting with source, the easiest thing for maintainers to dismiss, the least likely to be fixed and the most prone to magic hand-waving explanations ("experts only please") rather than thorough investigations.
Also, bear in mind that this is more of an emotional rant borne of ignorance and mild frustration.
Oh, and finally, several auto* tutorials and sites recommend reading the "Recursive Makefiles considered harmful" document. Are these techniques in practical use anywhere?
Drex & a creamy white paper request
This was what I was going to talk about originally so I'll keeping going despite the length of this post.
I've also been thinking of beginning to develop some of the concepts for Drex Authoring (-ing in a title is weird isn't it?) that I've thought about. I prefer the term authoring to the processing of words but it will have similarities to a word processor - ie. content is predominantly text. However, presentation of the content will exist symbiotically with the content rather than being integrated with it. More simply, the content can be created/edited and presented separately as needed. Drex Authoring is entirely about on-screen editing so I don't want to deal with physical limits like pages. I'd like the text to be displayed larger than your average word processor text (probably pseudo-zoomable), wrapping to fit the screen not the page but with typographic quality spacing. Additionally, I'd like a creamy white paper texture rather than a stark white fill for the background. Think of the nicest paper you've seen and nice crisp, black letters and that's it. I'd like to find a good procedural algorithm for the creamy paper to consistently generate the same texture results for a given (x,y) offset given a random seed (ie. no tiling).