Over the years, I’ve screwed with a lot of build systems. Both in the course of my own projects and other people’s, and I’ve come to a conclusion over the past fourteen years.

At best: you can reimplement make poorly. At worst you can reimplment half of autotools, poorly.

That’s pretty much what I’ve seen. Thus as time has gone on, I see it very hard to do better than good old Make. Especially when the GNU version has about five hundred pages worth of voodoo to appease even the worst masterbaters, and the need for autotools is kind of waning IMHO.

Enter ninja.

What I’ve generally found with Ninja is that it’s very simple. Like C: the little bit of syntax you need to remember is a small quantity. Opening a build.ninja file is probably enough to grok what’s going on if you’ve ever used an actual build system that involves editing files.

Likewise answers to questions that tend to make it easier to build a wonky, hellish, broken build monstrosity, tend to be “No, you can’t because that would make this slow”. And let’s face it, if you want much more than a relatively simple Makefile, you’re probably building a case for pain.

Based on the past year, I think ninja will be sitting next to vim and dump in my toolkit of loved and trusty computing companions.

When working off a local clone of code while I'm stuck sitting in a doctors office, I've got to admit, it would have been smart to have run make tags, and copied the resulting TAGS file over from the development environment to my transformer. Turns out it depends on more than just the usual tags generator >_<.

Oh well, I guess it's time to nav it the other way!

Sometimes Linus is a genius

When you begin to do more advanced things with subversion (not my idea, trust me), I would have to conclude using tarballs and larger hard drives is more useful than subversion.

For the first 10 years of kernel maintenance, we literally used tarballs and patches, which is a much superior source control management system than CVS is, but I did end up using CVS for 7 years at a commercial company [Transmeta^[11]] and I hate it with a passion. When I say I hate CVS with a passion, I have to also say that if there are any SVN (Subversion) users in the audience, you might want to leave. Because my hatred of CVS has meant that I see Subversion as being the most pointless project ever started. The slogan of Subversion for a while was "CVS done right", or something like that, and if you start with that kind of slogan, there's nowhere you can go. There is no way to do CVS right.^[12]

source: Wikipedia on Git.


Please, for the love of sanity (and science), do not use Subversion.....you have been warned!

Right, premake4 is one of my favourite ways to build C/C++ stuff but tonight I'm thinking it has a moron involved. You can specify a project as being one of four kinds: ConsoleApp, WindowedApp, SharedLib, StaticLib. The documentation here states that this likely means /SUBSYSTEM:WINDOWS will be passed to link.exe, and indeed it is. That is how you say call WinMain and do any other I'm a GUI app magic for Windows; other wise you get a main and a command  prompt; simply put.

This FAQ entry on the other hand, is just retarded.

Hmm, finally a chance to kick back and update my journal, before dinner ^_^. Something that's been on my mind, is task management and record keeping, or more broadly the issue of "Productivity".

When it comes to general coding or computing tasks, I stopped worrying years and years ago. I'm noted as a VIM user who loves its editing efficiency, and I would take something like vi or emacs any day of the week over a glorified Notepad, which is a class of code editor that excels at inserting efficiency. Likewise, I spend much of my time in a command line environment—which is far more productive for me than what most `normal` people use on their computer. Being at home in a terminal is also kind of a necessity where I work, hehehe.


So what does concern me, is at it's essence Getting Shit Done and Keeping Track of Shit Done. Over the past couple months, I've extended my natural workflow to something more effective for a working environment. In the end, it's still the same objective though, GSD and KToSD.


Traditionally, by project I would usually keep a set of notes: in the project root, either in a file called TODO or buf; which is a convenient name when your editing source code and want to write out a scratch buffer. Technical and personal notes would generally fall somewhere under ~/Documents with temporary notes and snippets in ~/tmp or ~/misc, depending on how long I need to cache it. Obviously, most of the interesting things would get converted to HTML and blogged here! My vim setup also defines an "Outline" mode that I utilize for brain storming and various other things that belong in a .outline file.

At the present, I'm utilizing a note taking program called TomBoy, which has become quite the useful notebooking tool! While it has a few things I find irksome or overly minimalist, it also has a few that I quite like, and fits the #0 rule: it just works. TomBoy is written in C# and works great on every platform I've tried it, including Windows. The main lack to it, is having to fumble about to find which window on screen belongs to my current note. I would like to find the time someday to write plugins for interfacing it with other software in my workflow but that's more so for use outside of work. My systems all run the TomBoy client and utilize one of the many backends for synchronization, so I always have an up to date set, which is good because (*groan*) sometimes I may have to work from home.


What I do with TomBoy, is maintain a set of notes: the Current Action List and . Whatever is most relevant to the here and now gets scribbled into the current action list. So for example, if I'm implementing some change to a program I will have outlined the phases needed to do it as a set of bulleted lists in my Current Action List note, which is saved in a notebook named after the company I work for. During a `change of gears`, or as certain information becomes less associated to the Here And Now of what I am working on, it gets cut and pasted into a note named after the project in the same notebook—so I know exactly where to find things. If a note becomes overly concentrated, becoming more like a multi-section collection, the notes get split and prefixed by the project name. I also have a "Programming" notebok for things that are of a more general programming nature, like comments about APIs or how to use certain tools. Today I added a "Personal" notebook, which will probably gain a Current Action List note of its own someday.


An example of this workflow in practice, earlier in the month I was focused on writing code to model a problem and code to test that for correctness. Kind of like an individual Test Driven Development. But I didn't have time to review things very well, yet I had gotten into this sweet work flow between coding, noting, and testing.  It got done and so did the code that needed to use it.


I outline what I need to do in TomBoy, using as little or as much detail as necessary, then I do it and adjust the note as necessary. It's for insurance: in case doing X takes N*4 times as long, or I suddenly have to take a shit in the middle of something, I won't forget to do the Xth thing. Out of convention, I prefix completed "Tasklets" with a '-' and highlight problem areas or WIP's with a '+' prefix, e.g.

 
• - change A
 
• - change B
 
• + change C
 
• change D

Where D is still to be done, C is giving me more overhead, and A and B have been hashed out.


This is helpful because for example, you might think of something Important(tm) that you don't need to focus on *now* but will need to _soon_. Or at least, it is helpful to me. I've been doing this for a while now and it's really meshing well. When a subject get hammered out, like A, B, C, and D all completed, tested, and committed; then I either delete the note text or transition it out of Current Action List and into Project Name. Just depends on whether or not the info needs to be retained.

Something that proved the utility of all this to me, was when I decided to take a step back and focus on examining the work I had done. So I took a couple hours to go over the programs code base, subject by subject, and making corrections as I saw preferable. To do that, I created two indented sections in my Current Action List: one for notes on application code and one for enumerating what the test cases actually cover. For each significant element that had changed during that cycle of development (probably ~50 commits), I did two things: review the test cases from the outside in, writing down what they actually tested (the assumptions), and an occasional (highlighted) comment about what needed to be tested for or changed. Then I opened the associated source code, and went through it and made any practical comments, in a form of super-short-review. This resulted in a Current Action List that looked like this:

Subject A tc ->
  * tests quux domain
    + includes ...
    + excludes ...
    + how it deals with X possiblity
  * and so on as appropriate, covering:
    + domains and ranges
    + state assumptions
    + error
    + and dealing with 'wtf was that?'
Subject B tc ->
  * ditto

Subject A ->
  Short, concise reviews
  * including comments with pointing out
  * and areas for change

Subject B ->
  ditto.

Looking at the assumptions the test cases make rather than the code it tests, showed me areas where the tests needed to expand, which showed me places that needed to be changed. To keep myself "Fresh", I paused after each subject/module to play "Fix it" to the flaws that I found in examining the tests and code, then update the note contents accordingly. Then I moved that chunk out of Current Action List and into Project Name. So if for example, before moving onto compiling the stuff for B, I would make the corrections to A that compiling the notes had found, then cut/paste it into the note for the project. I think this is a good thing, kind of like the old UNIX guys. I think it was DMR, who once commented on writing the BUGS section of a man page, only to go fix it rather than release it.

Doing that check the tests, check the code, fix the code cycle, allowed me to cover a lot of ground fast without having to worry about keeping track of minute details. I also didn't space out from reading to much code and writing to little, and still have it saved in case I need to reference it later.  After everything was done and I was ready to start the next phase of what I was working on, I transitioned all that stuff out of my Project Name note and into a note named "Project Name Test and Code Review", and left a line in "Project Name" to see that file for that. Clear, clean, and simple as eating.


Two reasons I love TomBoy: it has *excellent* support for lists and indentation. It totally and completely blows away software like gmail and Word in that regard, and provides the ease of use that my outline modelet in VIM was created to fill. It is incredibly easy to manage and manipulate info in a TomBoy note, and adapt it using list or indentation structure to organize a note in such a way that you can parse it at a glance. I generally use indents for sectioning, lists for enumerations. The second thing I love, is that whenever you write the name of a note or a file path it becomes a clickable hyperlink, very much like a wiki. But unlike the majority of wiki's it is tied to the name of an actual note (entry) rather than a SillyNamingConvention. There's also great support for renaming notes.




The thing that TomBoy is really Not So Good At, is managing TASKS instead of NOTES. It just wasn't designed to do more serious task stuff then a sheet of paper. Yet it is pretty damn good at the whole notebooking thing.


There is a program called Tasque but for my needs, it is much to simplisitic to be useful. In fact, Google Tasks in GMail is probably as good (and sucks). I gave Tasque a wurl because it had both a TomBoy plugin and a RTM backend. In testing that out, I found the TomBoy side of Tasque really ain't that spectacular either. In point of fact, just integrating RTM back into my work flow as proven useful. My usage of Remember The Milk has totally gotten overhauled, and it would be worth while to someday write a TomBoy plugin to help associate their notes/tasks.

I've basically replaced what fixed (and standard issue) lists I had with purely "Smart" lists, letting tagging and inheritance do the organizational leg work for me. This suits me, because I can set myself a task with tags that will make it show up in each list I want it to, so e.g. a task can be in both my list for work tasks and my list of people to contact, be readily searchable, and have a way of associating notes, due dates, and all sorts of handy stuff with it. Basically all the good stuff for tasks that TomBoy lacks.




That's the thing of it though,

• Just Work without Kicking.
• Let the software do the house keeping.
• Allow me to focus on working rather than structuring

And I'm quite happy, lol.

Well, while I'm waiting on a subversion command to finish (on another project), I may as well flush my train of thought, in between wondering how any large project can bare to use subversion lol.

One of my open loops is a component called the "Data Browser", it's meant to provide a view into data extracted from a projects source code, and present that data to the user: while bridging that browser interface into the rest of this programs peers. In less abstract English, it's a tags browser. Go figure.

Something I love about programming, you can often express a notion in 3 words of code, what would take 10 words of English to describe. How that works? You can reduce the English word count with the use of insider jargon, but being a programming language, outsider is redefined as those who can't read the language rather than those who don't comprehend the associated tech speak. There fore the word count falls significantly.

My present train of thought however, is concerned with how the data should be presented: what is most suitable for the user. The fact that the program is designed first and foremost for my own convenience is aside the point :-o.

In search of the holy grail of user interfaces: I've found this the most optimal method.

+---------------------------------+
|  [-] Classes                    |
|      [+] Foo                    |
|      [-] Bar                    |
|            someMethod()         |
|            ....                 |
|      [+] ....                   |
|  [+] Functions                  |
|  [+] Macros                     |
|  and so on                      |
|                                 |
+---------------------------------+

where as much information about the individual items has been omitted for the sake of brevity ^.

Properly expanding the tree for a given type of data should display information unique to it. I.e. what is most pertinent to *that* type of data, rather than a common subset that applies to everything.

Columns for a methods display might look like:

| name | signature | return value | visibility |

where as the columns for classes, as opposed to 'Bar', might look something like this:

| name | visibility | in namespace | 

.

In a perfect world we could do this over a sandwich without much coding. Using the GTK+ TreeView widget and friends, grepping the manuals suggests that life is just going to be waaay easier if each element (Classes, Functions, Macros, etc) of the tree becomes a separate tab holding a specialised treeview as part of a Notebook widget! I'll look into it closer when I have more time for that.

Now of course the tree view could simply show the lowest common denominator for info, and rely on a "Properties" button to show the individual details for the currently selected item, or we could (barf) just have expanding the trees spawn a new window customised to that type. But nether are to my taste.



Enough rambling, time to get a move on while subversion continues to (ab)use my networks bandwidth.

Here's to subversion: so damn slow that you can play galaga while you wait.

Today I've had to get used to living with Subversion again, as much as I simply love git, setting up a repository is easier with svn then git-svn :-S. Aside from the obvious problems that chop up from their different mental models it's not that bad.

The lights flickering as the thunder blares outside on the other hand, tell me that I should probably *WAIT* to merge this vendor branch into the trunk - and go look up how atomic svn copy src-url ... dst-url actually is in terms of network and power failures! If I was using git I would just say screw it and do the merge, because I know already that git doesn't phone home to the repository, because the working copy is a repository.

Oh well, to the manuals!

Quick & Painless C/C++ header installations using rake

In wrapping up and refactoring my new rake driven build system, I've written numerous utility functions. Most stuff specific to compiling crap is in a custom "Builder" module that provides a templated interface to the current OS/Compiler kit, via environment variables and methods like make_object, make_shared_library. My top level rakefile also has a neato inference rule rigged together for handling my triple-tree and quad tree build patterns.

The real fun of the day however, is this baby:

#
# A magic function that generates file tasks that copy all headers from
# directory ind # to directory outd.  Any missing directories are created as
# needed.
#
# The return value is a list suitable for the right hand side of a task, e.g.
#
#   task :headers => header_magic(src, dest)
#
def header_magic(ind, outd)
  dirs = []
  hdrs = []

  find_files(ind, /.*\.h[hxp]*$/) do |p|
    outdir = File.dirname p.sub(ind, outd)
    outfile = File.join(outd, File.basename(p))

    directory outdir
    file outfile => p do
      cp_r p, outdir
    end
    dirs.push outdir
    hdrs.push outfile
    CLEAN.include outfile, outdir
  end

  dirs+hdrs
end

find_files is another custom function, it simply takes a block and yields and file names matching the specified pattern. (In this case, more liberal than the usual header extensions but sufficient for my needs)

I call it header_magic, because it after all the other stuff I played with, it's the closest to Clarke's third law. Which is exactly what I want!

footnote: I just have my top level clean task nuke the entire build tree; so the CLEAN part hasn't been tested.

What exactly, 'is' my development environment?

I reckon this is something rather confusing these days, in most cases among younger folks, it will likely mean an Integrated Development Environment. To me, it just means the environment in which one develops stuff ;).

Being a lower level polyglot in terms of languages and tools, I generally keep a 'pallet' associated with each of my main languages, keeping things quite simple to work with:

• Build Tools:
• Some viable form of Make is required, generally I'll use local brew if an extension is needed. I prefer GNU Make over BSD PMake, as I find it more reliably cross-platofrom.
• CMake, while often little more than a poorly strung together bother, many projects now use CMake based build systems. It is actually a good tool but I don't favour it for use outside of a single OS family.
• SCons: powerful and effective, but often irksome to get a portable build. It's usually worth having available.
• Ant: you never know when you're gonna need it.
• Local brew of IDE and their background stuff, for example Visiual Studio for the vcbuild/msbuild modules and/or Code::Blocks. If I had a Mac, I'd likely have XCode handy.
• Documentation Tools
• Unix: troff/nroff and the usual macro packages. I actually like it.
• DocBook and XML/XSLT processing utilities. LibXSLT comes in handy.
• ReSTructured text and company
• Any local language related tools (e.g. for Java, Perl, Python, and C#)
• Doxygen: a multi-lingual documentation generator.
• Exuberant CTags: improved and vastly multi-lingual upgrade over ctags.
• TeX and LaTeX setups. I like TeXLive.
• Source Code Management / Version Control Systems
• Git -- must have!
• Anything I need to be handy with:
• CVS
• Subversion/SVN
• Bazaar/BZR
• Mercurial/HG
• C/C++
• I generally setup and maintain several compilers, multiple versions being welcomed. Generally I try to hang onto a member of the GCC 3 and 4 branches, and a fairly recent version of Microsoft Visual C++. Under unix-like and Windows systems respectively, I also tend to carry about a copy of PCC and Watcom.
• Java
• A suitable JDK, or a complete software development kit where appropriate.
• The GNU Compiler for Java can be useful.
• C#
• Mono and preferably the full stack of technology.
• Under Windows: several versions of the .NET framework and at least a workable version of Microsoft Visual C#.
• Python
• A copy of CPython, preferably both modern versions of 2.x and 3.x releases.
• The usual parts of CPython that some distrios strip out, like SQLite3 or Tk bindings.
• Another implementation for testing (e.g. IronPython) is appreciable.
• Perl
• A standard perl distribution, preferably the current major version or the one before it.
• Common perl modules one is actually likely to use someday.
• Lisp
• CLISP for general use, i.e. common lisp
• Armed Bear Common Lisp (ABCL) in case it eases deployment issues
• GNU Guile: my normal way to use scheme.
• Bigloo: a scheme compiler that's worth poking around
• Some other readily available Scheme implementation available, preferably one that is at least moderately R5RS compliant
• PHP
• Fairly recent version of PHP setup with
• Command line interp.
• Suitable Apache modules
• The CGI/FastCGI friendly thingy
• Ruby
• Current local-main line version.
• Rake build tool.
• A collection of handy modules
• UNIX shell scripting
• Something fairly portable, ash/dash based is nice.
• GNU BASH.
• Real and public domain versions of the Korn Shell.
• ZSH, my favourite.
• Go
• Standard distribution compiled from source.

GUI and Console versions of Vi IMproved being a very obvious requirement ;). I also tend to keep versions of Emacs, some flavour of MicroEMACS, and SciTE available in a pinch.  I like having ed available.

Generally some form of webserver, be it a quick tester (ala Python) or dedicated (I like nginx and Apache), is usually required: plus a decent web browser with javascript support.

Profiling, code generation, analysis, and debugging tools are almost universally welcome. I in particular like to keep Valgrind and GDB handy for a rainy day.

Like wise I prefer having certain libraries fully integrated into that stack, i.e. where appropriate having interfaces the common GNU/Gnome libraries (GTK+/cie), Qt3 and Qt4 libraries, bindings for SQLite3 and a major player (MySQL, MSSQL, etc), OpenGL, and so on and so forth. I tend to leverage both languages and tools whenever possible.

Someday I'll likely incorporate Lua, and dialects of Forth and ML into the mixture. Like wise I prefer a reasonably NAWK friendly version of AWK to be available. I also have interests in picking up Prolog, Haskell, Erlang, Ada, and a few lesser known languages, but just don't have the time to screw with such things a lot these days :'(. 

Simply put, where I go, a whole freaking lot of development tools go with me!

My thoughts on "Debugger Tips: 8 ways breakpoints can save your next software project"

Debugger Tips: 8 ways breakpoints can save your next software project: "Here are eight fairly simple techniques for using breakpoints and other features of your C/C++ debugger that can give you enormous power and visibility into your program.





"

An interesting article that's worth the reading, for anyone who is ever going to get stuck running a debugger. Personally, I prefer log files and analyzing the code in my brain, but when it's a task you can't cram up there in grey matter, or you need to cuddle up to the run time—a good debugger is your best friend.

Wew it's been a jumpin' hopin' day!

I was up all night fiddling with Code::Blocks and Stargella, plus work this morning, and ideas for an interesting project. However it's a project that would call for C++, and I hate C++, lol. I like C, but hate C++... funny. On the upside, I've finally gotten Stargella builds sorted out, and I'm tempted some what to hunt down and eliminate 'itches' here and there, but I'm not sure whether or not patches would be welcomed for some things that seem to be, to be good ideas. They've accrued a fair number of open patches and bug reports, so I don't think it's a highly active project. The code base is only about sixty some thousand lines, not to big for all it does.

Sigh, nothing but work on the horizon \o/. At least there's something on TV tonight that I haven't seen before, the original Night of the Living Dead. Geeze, what is it with all the zombie flicks lately? Compared to what I've seen of the remake (beginning / last half), it certainly has a more spirited beginning, bah I need some pop corn lol. I've no idea ottomh what they filmed it in, but it does give an interesting feel to the movie, different then most contemporary films of the era.

The price of pissing me off.

A word of warning, this post contains quite a bit of profanity after the jump break

After being up until well past 0400 last night, setting up a decent SCons build set on FreeBSD, for testing— its usefulness to this project. I started setting up the required config tweaks today on the Windows machine.

Oh how I love git, let me count the ways!

Initially I kept separate repositories for each portion, most notably the EPI core and build system. Since Trac was selected for part of our web stack for getting stuff done, and it can be a tad pissy about multiple repositories, I've opted to create a "Merged" repository from the others. Essentially the Trac will require multiple Trac environments or a singular repository; while my we take the time to decide which to use, I just whip up a solution out of my hat like a good little geek &(^_^)&.


The trees were located in dixie:~/Projects/EPI/repo/ and still are. After backing up the repositories, I created a new 'work' tree to become the home of this merger, threw them together, and did some clean up. First I tried using git filter-branch and git format-patch together with a few other mungies to get the history retained how I wanted it, then I decided to screw it and just make branches reflect the history—even better then what I wanted.


I then used git format-patch to create patch sets, placing them in temporary directories. Rather then change the patch sets to reflect the merge (good task for perl scripting), I decided to rely on git mv for something more full proof then hacking patch files by hashed out automata.

Creating a new 'work' repository, I made an initial commit with a stub file, then created suitable branches for each in my original repos, which is a task easily automated in sh or Perl, for people with lots of branches. A little bit of git checkout and git am, then slurped up the patch sets bringing each repository (and it's associated branches) under one roof.

Creating the new merged 'master' was a simple octopus merge.

$ git checkout master
$ git merge repo1 repo2 ...
$ git mv ...
$ git commit -a

Job done, good night!


Note also, I wanted the trees merged, so conflicts were not even present, hehe.

A little fun with git: publically exporting your local repositories

One of the great things about git, is it's distributed nature; in my humble opinion, being able to tell your partners to pull your latest code is a useful stop gap for code review (without better tools... for now, lol), then having to e-mail the flubber as a tarball.

In my case, I maintain my working tree on Dixie, usually stored under ~/Projects/ some where. To prevent freak data loss, I also push things out to bare repositories stored on Vectra, under /srv/git. Those repo's on Vectra are my "Centrals", which will usually get pushed out somewhere else (e.g. SourceForge) if the projects public. The fact that my home directory on Dixie is also backed up is also a bonus hehe.

In order to setup a suitable means for people to clone, fetch, and pull from my git repositories, I edited my Routers configuration, and set up a NAT (Network Address Translation) to forward a suitable port to Vectra. In Vectra's pf rulesets, I unblocked said port.

For write access, I use SSH and public key authentication to manage the repositories: and no one is permitted SSH access to any of my machines, unless they manage to break into my home wireless (or penetrate and suitably spoof my workstation), discover my username and hostname mappings, and brute force their way through the key pair before the internal firewalls tell you to F-off for good ;). In which case, good job monsieur or mademoiselle psychic!


Public read-only access may be setup with the humble git-daemon. Read-only access with controls, well is a task for something else ^_^.


The git daemon can be a fairly strict prickly pare about what it does export, so I feel reasonably comfortable with it. I created a simple whitelist file, called /srv/git/exports that describes what repositories may be exported: the file format is a simple line indicating the path to the repository to export publically, blank lines and those starting with a # comment being ignored.

I wrote a simple /etc/rc.git-daemon script that I can call from /etc/rc.local when OpenBSD starts, like so:

Terry@vectra$ cat /etc/rc.git-daemon                                            
#!/bin/sh

if [ "$1" = stop ]; then 
        logger -t GIT stopping git daemon
        kill -9 $(cat /srv/git/git-daemon.pid) && rm /srv/git/git-daemon.pid && logger -t GIT git daemon stopped
else
        logger -t GIT starting git daemon
        echo "$(cat /srv/git/exports | grep -E -v '^$|^#' /srv/git/exports )" | xargs git daemon --user=nobody --group=git --pid-file=/srv/git/git-daemon.pid --verbose --detach --export-all --syslog --base-path=/srv/git  && logger -t GIT git daemon started

        echo -n ' git-daemon'
fi

After this is executed, it's possible to:

$ git clone git://my.ip.addr.here/exported/repo/relative/to/base-path

as an extra bonus, since /srv/git uses my 'git' group for permissions but my umask by default tells everyone to screw off, I have to manually set permissions on repositories I wish to export, before someone can access them through the git-daemon.


Ok, so I'm nuts.

Combing vcbuild and vcexpress running at the same time, can lead to such interesting linkage errors if you try running vcbuild before saving the changed solution file back out ^_^.


Ok, no wonder I so much prefer just opening project files in vim, it saves me from having to launch the bloody IDE 8=).

Mating Vi IMproved with Visual C++, part I

Maybe it's because it is an Integrated Development Environment, but Visual C++ seems to be a little lacking in its handling of external editors (at least in the express edition I have avail). It seems the best way to get MSVC to work with Vi IMproved for editing files, is to right click on a file in the solution explorer docklet, and click "Open with". From there one can specify a program to open the file with and force it as the default editor; the down side is the bloody thing seems to reject the concept of command line arguments.

As such, I created a new win32 application in the IDE, and stripped the fundamental code down to the following

#define GVIM_EXE    _T("P:/Editors/Vim/vim-personal/gvim.exe")
#define GVIM_ARGS   _T("--servername"), _T("MSVC"), _T("--remote-tab-silent")

int APIENTRY
_tWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
          LPTSTR lpCmdLine, int nCmdShow)
{
        UNREFERENCED_PARAMETER(hPrevInstance);
        UNREFERENCED_PARAMETER(hInstance);
        UNREFERENCED_PARAMETER(nCmdShow);

    _texecl(GVIM_EXE, _T("gvim"), GVIM_ARGS, lpCmdLine, NULL);

    return 0;
}

Which means I get one instance of Vim running and double clicking files in the solution explorer, will open a new tab in the GVim window; gotta love an editor with a client-server feature hehe.


I have Michael Graz's visual_studio.vim installed along with the required python for windows extensions. The plugin loads and appears to be exactly the *first* vim plugin that I can actually find a purpose for using! Except for one small problem.... the plugin can't seem to chatter with the running instance of Visual C++ 2008 Express Edition!

Of course, I could likely jerry rig vim's :make command to invoke vcbuild for me without much trouble.



Heh, and just for the heck of it, I wonder if a similar plugin could be written for other IDEs, like Code::Blocks, XCode, and KDevelop?

I'm kind of happy with myself at the moment. I've found that Visual Studio project files are about the only reliable way I can get things to compile with Visual C++'s compiler on my lone windows machine. Since i greatly prefer using a command prompt for development work, having to alt tab between programs like VCExpress/devenv and Explorer windows are not something I'll put up with if I don't have to lol.


Since I do require a real mans editor, I set the IDE to load gvim as the default editor for source files; soon I'll rig it to use vim's client-server feature (:he client-server). Like wise that made Visual C++ little more then a very big project management and build system. Some weeks ago whilst looking for cl/link (compiler/linker) switches and a reference to nmake (Microsoft's make utility), I found the vcbuild utility; which is the "Visual C++ Project Builder - Command Line Version". So far it seems to be very suitable, which would mean the IDE is now only needed for managing the project and solution files, right? Well, not really!


When I started using Microsoft's development environment (this box only has the Express editions; I usually do development on my FreeBSD powered laptop!) the first thing I did was look at the .sln and .vcproj files it creates. The solution file (.sln) basically describes the bigger picture in XML format; for my present projects it does little more then reference the project files (.vcproj) that make up the solutions. The project files are also in XML, ''. It defines the various details, essentially what you get in the IDEs configuration manager for a specific project, and the files in the solution explorer. I was very happy to see Visual C++ using XML files, because it means I can *read* the things before opening them with an IDE.


Since the files are XML, and the format is pretty obvious: one can modify the project file quiet easily, and adding/subtracting things like source files, include directories, and libraries is a trivial task. If it wasn't for the use of ProjectGUID's I might never need to run the IDE again :-/. Who knows, maybe I won't even need that in a while lol.

Delightfully enjoyed this article

http://freshmeat.net/articles/stop-the-autoconf-insanity-why-we-need-a-new-build-system

I can also sympathize with the fictitious Joe and Jane in the examples — I have no love for the GNU build system / autotools. I've also had to waddle though ugly auto* files and deported documentation on occasion ;). The only part of autotools I do like, is GNU Make: because it is the most portable make implementation available, short of limiting things to a subset of the standard syntax.

I don't quite understand the authors comments about m4, because it is a pretty simple tool. Heh, I still remember watching The One on TV one night, and interspersing it with learning the m4 macro processor. IMHO m4 is an incredibly useful tool: being a fairly generic (yet expressive) macro processor lends itself to virtually any tasks that can benefit from pre or post processing. Although to be fair, for what most (smart) people would use m4 for doing, I typically (ab)use the C Pre-Processor (cpp) into doing for me \(^_^)/. The main reason I avoid using m4, is because I can never seem to count on a *consistent* set of behaviours whereever m4 can be found/ported, the last time I required m4 for a project, I ended up in a "F it, I'll make a C||C++ compiler a dependency" like situation: because the platforms m4 would not behave IAW the norm. It is a shame really, GNU M4 adds some nifty features (and even more shamefully, it was a ported/tweaked version of GNU M4 that was the problem child in the aforementioned situation lol)


When it comes to building things of my own, I usually create a Makefile; exception being Qt based stuff, in which case I generate makefiles with qmake ;). I've also considered implementing a Perl script that automagically does the right thing (or should I say, the infering the right thing) through a quick bit of build rules written in XML — but why do that, when there is a tool like ant? I personally like makefiles and GNU Make; then again I'll put up with virtually any make with $() and documented inference rules... hehe


SCons has been something tha thas been increasingly interesting to me, but unfortunately time constrants mean writing custom makefiles is a more economical use of time then learning a new tool like SCons :-/. Like wise, the main reason I have never adapted the Boost libraries is no time to fiddle with their build tool, which also interests me.

man, what the heck did we do before tools like git?


don't answer that.