makefiles howto: threadsafe mkdir

Directory creation within makefiles can now be handled in a consistent manner that is both thread safe and dependency driven. Directories will be created on demand and the mkdir command invoked within a shell only when needed. Bug 680246 has added utility makefile logic to support the functionality.

=== makefiles ===

MKDIR ?= mkdir -p
TOUCH ?= touch

# Dependency generator function
mkdir_deps =$(foreach dir,$(getargv),$(dir)/.mkdir.done)

# Target rule to create the generated dependency.
%/.mkdir.done: # target rule
        @$(MKDIR) -p $(dir $@)
        @$(TOUCH) $@

=== Problems ===

  • inlined “mkdir -p” calls have built in overhead. A shell must always be spawned even when directories exist.
        mkdir -p $(dir $@)
        touch $@
  • Placing pre-requisite dependencies on directories can be problematic as they contribute to generation of dependencies that are randomly stale (example:
    foo/bar.out: foo
        touch $@
        mkdir -p $@
  • Race conditions for make -j creating directories and targets.

=== why the extra dep? (.mkdir.done) ===

Placing dependencies on directories is a very old makefile problem. They contribute to generated targets being artificially stale even after gmake has been run. Make will query the inode table when making timestamp comparisons. Unfortunately whenever directories/files/links are created/deleted/modified/renamed within a directory the inode table alteration will be detected by make as a stale dependency/target to regenerate. Generated targets that have the directory as a pre-requisite are re-created whenever the directory timestamp is newer than the target. This can occur immediately after a successful gmake run.

==== mkdir_deps: user function ====

A simple workaround for these problems is to use real makefile dependencies to control if/when a directory should be created. The user function ‘mkdir_deps’ can be called, passing in a list of directory paths. The function will return a list of arguments suffixed by the filename ‘.mkdir.done’.

include $(topsrcdir)/config/
deps = $(call mkdir_deps,foo,bar,tans)
$(info deps=$(deps))

deps=foo/.mkdir.done bar/.mkdir.done tans/.mkdir/done

==== mkdir_deps: target rule ====

The second component if the library is a wildcard target rule that will match (~directory) dependencies suffixed by ‘.mkdir.done’. The rule will use the given target name to create a directory and dependency file contained within that directory.

    $(MKDIR) -p $(dir $@)
    $(TOUCH) $@

==== dependencies ====

Using dependencies for directories have a few benefits. They convey filesystem state information to gmake so the command can decide when a directory should be created rather than spawing a shell to run a command that will determine if the directory should be created. The dep can be mentioned as often as needed (pre-requisites) to trigger directory creation. Overhead for each reference will be a file stat or far more likely checking cached filesystem information.

With dependencies in use, existence of a .mkdir.done file will short-circuit all directory creation attempts because the target is up-to-date. To resolve race conditions and critical section problems when a directory does not exist, “mkdir -p” will step in. When multiple threads attempt to create the same directory one thread will win and create it. All other threads will attempt creation, fail and ignore status because the directory already exists.

=== USAGE ===

==== Multiple makefile targets ====

By far the simplest syntax to use for directory creation is when multiple targets in a makefile require a common directory. Assign a list of directories to GENERATED_DIRS then include Dependencies will be generated to automatically create and remove (clean target) directory deps as needed.

dirs = foo bar tans
include $(topsrcdir)/config/

    find $(dirs) -ls


  • simple syntax
  • automated cration and cleanup


  • Shotgun approach, deps created may be irrelevant to a target.

==== Individual makefile targets ====

GENERATED_DIRS may be a fast and easy answer but it is not always correct. Sometimes a more refined answer may be needed . Logic requiring directory creation by common logic residing within an included makefile or may be target specific can directly utilize the mkdir_deps function to create pre-requisites. An example of unwanted dependencies would be “gmake check” being able to create a directory only used by the install target.

Creating individual targets

  • Declare a local make var for the directory dependency or use ${target}-preqs if a target is using several.
  •  $(call mkdir_deps,dir[,dirN]) to generate dependencies.
  •  Assign deps to targets as needed.
  •  Declare ‘GARBAGE_DIRS =’ if ‘gmake clean’ targets are allowed to remove the directories.
dirs = utils
GARBAGE_DIRS += $(dirs) # gmake clean

include $(topsrcdir)/config/

# call mkdir_deps after has defined the function.
# allocate dep once for re-use
dir-utils = $(call mkdir_deps,$(dirs))

# inline dep allocation for pre-requisites
install-preqs =\
  $(call mkdir_deps,install_here) \
  $(dir-utils) \

install: $(install-preqs)

export: $(dir-utils)


  • surgical approach. Directory creation can be target specific.


  • manual clean target removal required.
  • care must be taken when deps are used as a pre-requisite to produce correct behavior.

==== caveats ====

  • mkdir_deps should be called after the function has been defined by “include”. Calling prior to the include will return $(NULL) rather than a dependency — handled by make as a NOP instead of a directory creation request.
  • Be aware of how dependencies are being used as a pre-requisite for targets.
    • Common targets [export, libs, tools] are internally flagged as phony by and will function correctly.
    • Targets explicitly marked as .PHONY: will function correctly.
    • Targets that contain other sources as a pre-requisite will function properly.
  • A target that has no pre-requisites and are not .PHONY will not function properly w/o help.
dir = $(call mkdir_deps,mydir)
target: $(dir) > $@

After the directory is created on the initial call subsequent checks will determine {erroneously} that the .mkdir.done dep exists and is older than the target so no work is required. At a minimum the target should be dependent on *.sh and any other related sources or timestamps so target processing will be conditional on change and not simply on directory existence.

==== example ====

Directory creation is easy. Conditional directory creation is also supported with use of the $(if ) makefile directive.

configure:: configure-files
        @if test ! -d $(MOZ_OBJDIR); then $(MKDIR) $(MOZ_OBJDIR); else true; fi
        @if test ! -d $(OBJDIR); then $(MKDIR) $(OBJDIR); else true; fi
        @echo cd $(OBJDIR);
        @echo $(CONFIGURE) $(CONFIGURE_ARGS)
          || ( echo "*** Fix above errors and then restart with\
               \"$(MAKE) -f build\"" && exit 1 )
        @touch $(OBJDIR)/Makefile

Using mkdir_deps(), the creation calls can be written in terms of make dependencies and listed as pre-requisites for a target. In place of in-lined shell commands reducing the number of shells that will need to be spawned.

configure-preqs = \
  configure-files \
  $(call mkdir_deps,$(OBJDIR)) \
  $(if $(MOZ_BUILD_PROJECTS),$(call mkdir_deps,$(MOZ_OBJDIR))) \

configure:: $(configure-preqs)
        @echo cd $(OBJDIR);
        @echo $(CONFIGURE) $(CONFIGURE_ARGS)
          || ( echo "*** Fix above errors and then restart with\
               \"$(MAKE) -f build\"" && exit 1 )
        @touch $(OBJDIR)/Makefile

=== MAKEFILE: ===

* Directory dependency makefile example.
* Howto generate stale makefile targets.

# -*- makefile -*-

all: work/dep-on-dir work/dep-on-file

work/dep-on-dir: work
	date > $@

	sleep 3; touch $@

dep-3: work/dep-on-dir
	touch > $@

	@mkdir -v -p $@

	$(RM) -r work

	/bin/ls -dl work work/*

===== Frst attempt: clean state =====
  • No targets exist, create directory 'work' and files 'dep-on-dir' and 'dep-on-file'.
  • Sleep to ensure dep-on-file will have a newer timestamp than the containing directory 'work'.
% gmake -f clean all
rm -f -r work
mkdir: created directory `work'
date > work/dep-on-dir
sleep 3; touch work/dep-on-file
  • Directory 'work' and both files exist so dependencies are expected to all be up-to-date.
% gmake -f show
/bin/ls -dl work work/*
drwxrwxr-x 2 joey joey 4096 2012-04-12 12:12 work
-rw-rw-r-- 1 joey joey   29 2012-04-12 12:12 work/dep-on-dir
-rw-rw-r-- 1 joey joey    0 2012-04-12 12:12 work/dep-on-file
===== Second attempt: timestamps are incorrect, tasks needlessly performed =====
  • Re-run gmake a 2nd time to verify the assumption that all targets are up-to-date. "Nothing to be done for 'all"" should be reported.
% gmake -f all
date > work/dep-on-dir

Alas no, since dep-on-file was modified 3 seconds after the containing directory 'work' was created dependencies are stale yet again and make will need to re-create dep-on-dir when called.

===== Third attempt: success =====
  • Run make a 3rd time. Work is now newer than 'dep-on-file' so we are finally up-to-date.
% gmake -f all
gmake: Nothing to be done for `all'.
===== The plot thickens =====
  • At least for this example the dependencies are now up-to-date after running gmake adnauseum (not a good practice...). The problem worsens as dependency chains expand and intra-target chains form circular dependencies that invalidate one-another or are forced to always be stale triggering rebuilds. As more dependencies are placed on work/dep-on-dir (target: dep-3) the chain will contribute to even more stale dependencies that require additional time and effort to try and resolve.
dep-3: work/dep-on-dir
    touch $@

% gmake -f clean all
date > work/dep-on-dir
touch dep-3

## dep-on-dir, dep-3 and any targets dependent on them will be considered stale.
% gmake -f all
date > work/dep-on-dir
touch dep-3
  • To uncover dependency problems like these, always run make twice in succession after modifying your makefiles.
% gmake clean all; time gmake all
gmake: Nothing to be done for `all'

If "Nothing to be done' is reported dependencies are functioning properly. If make reports any other progress status or spends a lot of time doing nothing the makefile should be reviewed. This is a clear sign that dependencies are not correct which in turn will forge gmake to spending extra effort needlessly regenerating targets, dependencies and doing random work.

Posted in makefiles | Tagged | 1 Comment

An interesting view outside this morning

A double rainbow: photo #1, photo #2.

Posted in Uncategorized | 1 Comment

makefile landmines

Makefile landmines: avoiding limb loss

[ps] ignore a similar makefile post I made yesterday. Somehow draft+update implied publish and the original content was not yet ready to see the light of day.

When writing makefiles there are a few logic bombs to try and avoid as they can mask failure conditions. When command exit status is ignored or overlooked the site can become a source for random failures or manifest in downstream testing.

A few problem sources to mention are:

  1. Not returning, propagating, testing for or ignoring shell exit status.
  2. Use of line continuation to join multi-line commands within a makefile.
  3. Prefixing commands with a hyphen ‘-‘ to ignore errors.

A simple makefile ( is attached below that will illustrate problem space for items #1 and #2 using the true & false shell commands. True will succeed with a shell exit status of zero (0==$?). False will fail with a non-zero exit status:

% gmake -f show
makefile target is: show
     /bin/true: $?=0
    /bin/false: $?=1

% gmake -f pass
makefile target is: pass

% gmake -f fail
makefile target is: fail
gmake: *** [fail] Error 1

Line continuation: why they can be a problem

Line continuation is an efficiency that is often used to avoid the overhead of having to spawn a new command shell for each command mentioned in a target rule. Most of the time line continuation will function as expected but when exit status is lost or over-written, success is returned allowing make to return a false-positive.

An easy way to create this condition is by wrappering the logic in an if block. Commands can merrily fail in bulk within the block but final exit status will be set by the shell if/test condition — which always succeeds.

This can be illustrated by the makefile target ‘bad‘. Run the true command, then false and if all is well the target should fail on the false call. Guess what, we have opened a logic hole for bugs to quietly sneak in through:

% gmake -f bad
makefile target is: bad
if [ ! -e '/non/existent/file' ]; then 
            echo "ASSERT: should not reach this point"; 
ASSERT: should not reach this point

There are a few workarounds for this problem space. One of the easiest is use of the shell ‘-e’ set/command line arg. When enabled a shell will exit immediately with non-zero status whenever a command fails.

Uncomment this line in the and the command will fail as expected:
    SHELL := $(SHELL) -e

% gmake -f bad
makefile target is: bad
gmake: *** [bad] Error 1

The -e option or a morale equivalent is supported by bourne, bash, dash, ksh or whatever other shells people may prefer to use.

suggestions: line continuation alternatives

  • At a minimum for readability consider using GNU make’s .ONESHELL: directive in place of large line continuation blocks:

  • Avoid line continuation wherever possible. Make is very good at control flow and processing but not so much as a scripting language. Blocks that span more than ~5 commands or are encapsulated within an if block would be ripe for breaking up into several distinct makefile goals {better yet general targets in a makefile library} or moving the entire block into a shell script that will be invoked by the target.
  • shell/set -e flags should be enabled everywhere to improve error detection along with options to detect uninitialized variable usage. Functionality is already enabled by in a few places with use of the $(EXIT_ON_ERROR) make macro defined in config/ Listing $(EXIT_ON_ERROR) as the first item of a target rule will be expanded by make into $(SHELL) -e @command_text enabling fail on all command failure handling:


    EXIT_ON_ERROR = set -e; # Shell loops continue past errors without this.


        for f in $(subst .cpp,$(BIN_SUFFIX),$(CPP_UNIT_TESTS)); do 
          XPCOM_DEBUG_BREAK=stack-and-abort $(RUN_TEST_PROGRAM) $(DIST)/bin/$$f; 

    Make judicious use of sh -e functionality but do not blindly trust that the option has been enabled for a given makefile target. There will not always be a visual cue that the flag is active. In this case if the EXIT_ON_ERROR macro were inadvertently cleared or commented out a subset of error detection would be lost. Best option initially is to manually verify the failure condition then write a negative unit test to back up the assertion long term.

    • One trivial way to validate logic blocks like these is leverage the try server and modify the makefile to perform a negative test. Simply inline a call to 'exit ###' as the last statement in a block. Submit makefile edits that are guaranteed to fail then verify all platforms reported the failure everywhere: in logfiles, email and tbpl web status.
          if [ 1 -eq 1 ]; then
          && /bin/who 
          && echo "********************************"
          && echo "Failure forced"
          && echo "********************************"
          && exit 99
      % ${EDITOR}
      % hg qnew patch.try
      % hg qref --message "try: -b do -e -p all -u all -t none"
      % hg push -f try

      If all goes well failure email will soon be on it's way. If the makefile fails with status 99 the negative test succeded. Be careful of errors reported early by ps or who, status could still be ignored by logic later on. ($?==99) is the only exit status that should be used to assert the negative test passed:

      gmake: *** [all] Error 99

      Negative testing can be as important as positive testing and will sanity check two important items. First that the exit/error status was properly detected and make was able to generate and record an error in the logs. Second, the failure status was able to propagate through the try server and was reported accurately by the web interface and through status email.

      If either condition is not met a bug should be opened so the logic can be modified to prevent any future failure conditions from silently sneaking into the tree. If negative tests are not able to force a failure conditions valid errors that occur while building/processing will not either.

    • The configure script would also be a place to perform similar -e tests.
      Often when commands cannot be found or failures occur the configure script
      is able to run to completion but underlying failures are lost in the

    • Lastly a plug for testing. If you will be expending effort to test makefile logic go the extra setup and write a unit test and add a 'check:' target to automate the activity. Even if the test is a trivial smoke test initially it can be expanded later. Start with these three conditions, if any fail something has gone horribly wrong and may needlessly waste queue time and build resources:
      • positive test: target does not exist initially, generate and verify.
      • negative test: target cannot be created and test fails.
      • nop test: target exists, minimal overhead should be imposed. If a target performs work when up to date think of how much time is being wasted by the sum of all targets with this behavior.
      % gmake -f check
      makefile target is: check
      Running positive test
      Running negative test
      Running negative test [failure forced]
      gmake: *** [check] Error 1

    Ignoring errors: hyphen prefix for commands

    AKA I do not care what type of explosion occurs on this line, ignore status and always return success.

        @echo "Inhibit target rule errors"

    There are a few legitimate places where this option can be used.

    • File deletion on a system that does not support rm -f.
    • Shell/OS command bug that will force returning non-zero status for

    command that should succeed (~transient problems).

    Aside from cases like these, use of a hyphen in general makefile logic to ignore a set of failure conditions will have an ugly side effect of also ignoring an entire set of unrelated problems. In the filesystem and OS area, that a target should be aware of and fail on.

    Ignoring conditions like say a file being conditionally non-existent when a target is processed because the file will be generated by the target is one example. Hmmm, this might also be an instance of trying to work around a line continuation problem, testing for file existence and subsequent loss of command exit status within the if block.

    In place of using hyphens to code around a set of conditions remove them outright and use an external shell script to do the right thing. Handle conditions, test for existence and return an overall shell exit status from the actions. If anything fails always return non-zero.


    Here is a sampling of makefile code from the tree with problems mentioned above. Not trying to pick on anything specific, just what can be found with a bit of poking around.

    • toolkit/locales/
      ** -cp -r $(JARLOG_DIR)/en-US/*.jar.log $(JARLOG_DIR_AB_CD)
      ** -$(PERL) -pi.old -e "s/en-US/$(AB_CD)/g" $(JARLOG_DIR_AB_CD)/*.jar.log
      ** A few conditions these commands will succeed on:
      *** Source files do not exist. When file existence is not mandatory $(if ) conditions and extra target rules can conditionally copy when needed. As could an external shell script that could bundle several statements and eventually be tested.
      *** Destination directory does not exist or filesystem is full.
      *** Source file is not readable.
      *** Destination file exists but is not writable.
      *** $(JARLOG_DIR_AB_CD) does not exist and we attempt to copy files into the directory.

    • js/src/ctypes/libffi/
      ** -rm -f src/alpha/ffi.$(OBJEXT)
      *** -rm is implied by the $(RM) macro: RM = rm -f
      *** Written as: $(RM) src/alpha/ffi.$(OBJEXT)
      ** -test -z "$(lib_LTLIBRARIES)" || rm -f $(lib_LTLIBRARIES)
      ** -test -z "$(noinst_LTLIBRARIES)" || rm -f $(noinst_LTLIBRARIES)
      *** Avoid spawning extra shells
      *** $(RM) will not fail when the macros are empty
      *** Written as: $(RM) $(lib_LTLIBRARIES) $(noinst_LTLIBRARIES)

    • config/
      * clean clobber realclobber clobber_all:: $(SUBMAKEFILES)
      * -$(RM) $(ALL_TRASH)
      * -$(RM) -r $(ALL_TRASH_DIRS)
      ** -$(RM) is redundant of $(RM) unless RM != /bin/rm -f

    Sample makefile:

    # -*- makefile -*-
    ## Intent: makefile landmine examples
    ifneq ($(null),$(MAKECMDGOALS))
      $(info makefile target is: $(MAKECMDGOALS))
    SHELL := $(SHELL) -e
    all: pass fail bad
            if [ ! -e '/non/existent/file' ]; then 
                echo "ASSERT: target $@: should not reach this point"; 
            @echo "Running positive test"
            @/bin/true && echo "OK" || exit 1
            @echo "Running negative test"
            @! /bin/false && echo "OK" || exit 1
            @echo "Running negative test [failure forced]"
            @/bin/false && echo "OK" || exit 1
            @if [ 1 ]; then
                /bin/true;  echo "     /bin/true: $$?=$$?"; 
                /bin/false; echo "    /bin/false: $$?=$$?"; 
Posted in makefiles | Leave a comment

Build system tools: make-makefile, file generation

This post will be article #2 in a series about the build-config tool make-makefile.
The series is being written to formally document current tool functionality and
provide a base for future topics related to the container makefile project.
Container structure, functionality and example usage.

Series posts

When makefile generation is needed the tool will perform a few steps.

  1. gmake -f is invoked. During traversal if gmake detects one
    of two conditions the tool will be invoked to generate a Makefile:
        o $(obj)/Makefile does not exist.
        o $(src)/ is newer than $(obj)/Makefile.
  2. Target rules used to invoke mm live in config/ near line 1342 and 1347
        o 1342 Makefile:
        o 1343 @$(PERL) $(AUTOCONF_TOOLS)/make-makefile -t $(topsrcdir) -d $(DEPTH)
  3. make-makefile will be passed -d and -t command line arguments:
        o -t path to root of a development sandbox ~$(TOPSRCDIR)
        o -d relative path –depth from file to hierarchy root directory.
    Makefile: $(MOZ_OBJDIR), $( TOPSRCDIR)
  4. When invoked make-makefile is aware of the directory hierarchy and will expect cwd for the shell to be $(MOZ_OBJDIR) or a subdir of it [1]. config/ logic will place make-makefile in the target directory for each makefile to be generated [2].
  5. Step 1 – obtain values for depth, topsrcdir and objdir.

    Values will be:
        o used to construct directory and file paths.
        o perform text substitution within templates.

    Values can be:
        o explicitly passed on the command line.
        o determined from the filesystem based on arguments and/or cwd.
        o extracted from file arguments.

    $depth will be set by:
        o Explicitly using the -d command line argument.
        o Assignment of DEPTH=../.. specified within an individual Makefile.
        o Assignment of DEPTH=../.. within any other files passed on the command line
          (is this behavior a bug or feature?).
        o Assignment of DEPTH=../.. contained within a parent directory Makefile [3], [4].

  6. Step 2 – Using cwd and arguments, derive paths to the source template and generated target file Makefile.
  7. Step 3 – Slurp the source template Perform value substitutions
    on tokens embedded within the template of the form @token@.

    DEPTH = ../../..
    topsrcdir = @topsrcdir@
    srcdir = @srcdir@
    VPATH = @srcdir@

    Some directory/file paths are derived internally by the tool for quick substitution. For any @${unknown}@ tokens make-makefile will delegate expansion with a call to system(“./config.status”) [5] to obtain values, create directories and who knows what else. Shell overhead will be imposed by this step so avoid unnecessary tokens when possible. When only a handful of tokens are in play one optimization to check on is if mm could derive values for the tokens and avoid overhead from calling the config.status script [6].

  8. Step 4 – update or preserve generated Makefile timestamps. If obj/Makefile does not exist create it. If the file exists compare generated content against the original and only update when modified.


[1] The requirement of cwd==$(MOZ_OBJDIR)/ can be removed with use of the –enhanced flag. This option and other new flags will be covered in a future post.
[2] Enhancement: a response file could be used to support bulk makefile processing and directory creation (by config.status) saving some shell overhead. Bulk processing might also reduce the number of times config.status must be invoked independently.
[3] Potential bug. DEPTH= searches within multiple files could set $depth incorrectly when it is not explicitly set within a makefile. One ex would be passing browser/…/Makefile and js/src/…/Makefile as command line arguments. Though this error condition exists it is not likely to be triggered as files are processed individually.
[4] Potential bug: checking ../Makefile for ‘DEPTH=’ will fail for makefiles invoked from a parent directory several layers above cwd.
[5] Enhancement – modify make-makefile to parse and extract fully expanded values from config* to avoid invoking ./config.status for a subset of substitution tokens.
[6] make-makefile will issue a warning when the ./config.status script will be launched
WARNING: token SET_MAKE not defined
line 2, src: […..]/js/src/ctypes/libffi/


Tool source

Unit tests


Pending enhancements

  • Expand test coverage for make-makefile
  • Add Response file support.
  • Rewrite unit tests in python.
  • Porting make-makefile from perl to python.
  • minimize shell overhead from config.status use

Future Blog Topics

  • make-makefile args and enhancements to generalize logic and support container builds.
  • Container makefiles: scripts & config
    • template files
    • non-invasive makefile edits to support container builds
  • Container makefiles: bulk file processing
    • => Makefile
    • *.idl => .h, .xpt, and deps .xpt.pp
    • makefile targets: export, tools, libs, test, *
    • thread mutex from target modifiers and extra container dependencies
  • Makefiles and library logic
    • threadsafe mkdir library function
    • config/ modularity – isolating logic based on bulk build types
    • thread mutex from target modifiers and container dependencies
Posted in build tools | 2 Comments

Build system tools: make-makefile

Build system tools: make-makefile

The build process consists of several steps, one of which is the dynamic generation of makefiles – the creation of recipes that control how and when elements of firefox and friends are generated.  The tool currently used for generation is make-makefile, a utility written way back in the days of Netscape (circa 1999).  Intent for this post and a few more that will follow will be to document the tool and usage.

Program and config
* build/autoconf/make-makefile
* build/autoconf/
* build/autoconf/make-makefile.excl

make-makefile will be automatically invoked while building whenever a Makefile does not exist beneath the object directory or a template ( is newer than a previously generated Makefile.


Posted in build tools | 1 Comment

NYC – The City that Never Sleeps? Not so much.

On Friday, July 29, 2011, after completing my first work week with the rest of the Release Engineering team in Toronto I left for the airport around 3pm to catch a flight home to Albany, NY. The week went well and everyone had a great time, visited plenty of good restaurants and pubs along with a trip to the new office (under construction). Little did I know what adventure lay ahead on the trip back home. Here is the abridged version of the chain of events.

  • My Air Canada flight from Toronto to La Guardia was scheduled to depart @ 7:15pm EDT. Upon arrival at the airport the ticket agent mentioned that the flight had been delayed. My connection from NYC to Albany would be missed, but figured the flight could be straightened out on the ground in LaGuardia.
  • Sent a text to my wife Lisa to let her know what was going on and she told me heavy thunder storms were in the forecast, moving out around 10-11pm.
  • Not long before we were supposed to board the plane, the flight was delayed a 2nd time to 9:00pm EDT
  • A 3rd gate change delayed departure until 9:40pm EDT.
  • Finally boarding, the flight was supposed to leave at 9:40pm, but we are still sitting on the runway at 9:48. We spent another 20-30 minutes taxiing and waiting for overhead traffic to clear but at least we are on the plane!
  • Oh, did I forget to mention one kid played basketball in the waiting area for 2hrs. Dribbiling, lay-ups on glass by the check in desk. What a special treat for everyone in the waiting area…
  • Landed at La Guardia around 11pm on Friday night to find out that the US Air flight @ 9:29pm was the ONLY flight available and was clearly missed. The earliest flight out to Albany would be sometime on Sunday.

Yes things were not looking good. Called Lisa again to let her know what was going on.

  • Began calling car rental companies from the airport. Lovely, these multiple choice answers can be used for all of them:
  1. Business is closed after 10pm
  2. All vehicles have been rented
  3. Vendor will not rent vehicles one-way, must be picked up and dropped off at LaGuardia.
  • So, onto hotels, maybe I could rest for the night and try to pick up an early rental return. Well Deja-vu:
  1. No Vacancy – on a Friday in NYC, go figure…
  2. No shuttle service available between the hotel & airport
  3. No answer at the main desk or through central reservations
  • Called Lisa back with an update, with her having never driven in NYC let alone La Guardia and the fact that it was getting late with a ~3.5 hour drive looming overhead. Having her drive down for a pickup did not seem like a good idea.
  • In the meantime, Lisa was trying to find alternate transportation. She checked the Amtrak schedule but both early morning trains on Saturday were sold out. Also friends we know in NYC were out of town so the streak of bad luck continued.
  • Lisa found the Metro-North Railroad (commuter train) schedule online and suggested I take a cab to Grand Central Station and try to catch a train to Poughkeepsie NY. The drive would be less than 2 hours from home and she could pick me up. We thought worst case scenario, at Grand Central Station I would have a place to stay until the next train, so that was the plan.
  • My cabbie made really good time from the airport, even with some construction delays. Figures, arrival time at Grand Central was not long after the 1:50am train for Poughkeepsie left the station so I was stuck waiting around until 6:20am.

Yes 11 hours and counting.

  • Well hello there Murphy how have you been? Last train departs Grand Central at 2am and police begin sweeping vagrants out into the street shortly afterward. FYI, the station closes from 2am to 5:30am daily. Two young teenage girls and a boy were in the same predicament but luckily an officer made arrangements for them to remain in the dispatch office rather than having to fend for themselves.
  • So at 2:00am I joined the ranks of NYC’s homeless. With my knapsack and suitcase in tow started walking the streets of Midtown Manhattan. I can easily say that nothing heightens your awareness like having “tourist”, “mobility impaired” and “come rob me” stenciled in neon on your person while walking around the city.
  • Must have walked at least 40 blocks around Park Ave. Lugging a knapsack loaded with books and a laptop around for 3+ hours is loads of fun, I highly recommend it especially when you are bored with nothing to do and tired.
  • Looked for a 24/7 coffee shop nearby but there was nothing open.
  • It was really hot and muggy that night (mid 70s), while roaming the streets, kept texting Lisa so she would know I was still breathing.

Depressing, saw at least 20 homeless people sleeping on street grates, benches, building steps and in alleyways. Ages ranged from teenagers to the elderly. Some people were so contorted from being slumped over on a hard bench with relaxed muscles there should have been damage from snapping or dislocation. Not sure how two people were even able to breathe given the position they were in. I did see one very odd group of “nappers”. They appeared to be clean/fairly well dressed with a few pieces of luggage, wondered if they also had the pleasure of being booted from Grand Central.

  • Around 4:45am managed to find a local grocery store open and was able to get something to drink but didn’t want to hang around. If this is the city that never sleeps I am not convinced!
  • At 5am the entertainment arrived, bars were closing and it was time for the severely inebriated to meander home. Good thing most of the travelers were couples, leaning into each other and staggering provided enough forward momentum w/o drifting out in to the street or light fixtures very often. All in all this was probably the most amusing point of the night.
  • After completing my walking tour of NYC, shuffled back to Grand Central in time to board the 6:20am train bound for Poughkeepsie.  Lisa sent a message that she was on her way to pick me up.

It is a little over a 90 minute drive from home but near her parents so she knew the area. Neither one of us were able to get any sleep the night before and were running on pure adrenaline.

  • My train rolled into the Poughkeepsie train station at about 8:30am and Lisa was waiting for me on the platform. We were both tired but we hopped back into the car , made a quick stop for breakfast at a drive through and headed home.
  • We got home about 10:40am and crashed at about 11am; don’t think we were conscious again until 6:30pm.

So there you have it, 20 hours of non-stop excitement after an awesome work week in Toronto. In the grand scheme of things this is small potatoes but I thought everyone would appreciate a good laugh; Murphy’s Law certainly took over. This concludes my little NYC adventure. I wonder what my next trip has in store… Can’t wait!

Until next time.

Posted in Uncategorized | 7 Comments

Hello from the Adirondack Mts

Welcome to my inaugural blog post! I’ve read plenty of blogs but never saw myself actually writing one, so this is uncharted territory for me.  It sort of feels like it did last Saturday while helping my father back his boat into Chateaugay Lake, I ran out dock while directing him and plunged into the lake, clothes, Droid and all!

I figured I’d stop in and day “Hi” before I run off for 10 days for our annual camping trip in the Adirondack Mountains. We plan these trips a year in advance and hope Mother Nature is kind to us; the weather in the Adirondacks can be unpredictable. Breaking down camp in the pouring rain may be a fun challenge for some but doing it in a torrential downpour is something I could live without doing again for a very long time.

As John stated in his blog post, I am wading through TONS of “stuff” to familiarize myself with Mozilla’s Makefiles. Thank you John for the Welcome BTW and thanks to those who have been patient and answered my questions so far.

Photos from the trip will be forthcoming, until next time!

Posted in Uncategorized | Leave a comment