I’ve just tried to checkout Pebble’s source, and build the evolving version of 1.5. I couldn’t do it. There weren’t any instructions on building that I saw, so I tried a few things.
- Run the setenv.bat file. This seemed to mess up my
ant -projecthelp. This gave me a
ant. This gives me
TagUnitTask cannot be found.
I don’t have the time or energy to dig in and figure out how the build system works, so for now I’ll wait. It’s hard to have all of the Prime Directives right all of the time.
I didn’t want to lose this link since the idea seems pretty cool to me. There are two major points: 1. Using a Knoppix CD you can boot onto most machines, including those in stores. USB keys might be used instead or as a supplement. 2. You may be able to use Knoppix to access a dead Windows drive, or even as a replacement to Ghost.
Anyway, there are some cool ideas there.
What a better way to spend New Year’s Day after a hard week than updating my Gentoo box and watching the West Wing. Life is good.
deseretnews.com — Nature takes toll in Utah, West
“We broke that one-day record with Friday’s storm,” Eubank said. “The most snowfall for any 24-hour period was 18.4 inches on Oct. 17-18, 1984.”
This monster snow storm delayed my in-laws trip to visit us in sunny Arizona by more than 8 hours! I may include details later, but it was a day of endlessly shifting plans.
It’s been quite interesting to play with Ant 1.6. I’ve trying to figure out the best way to share
macrodef snippets between projects, and I think I found my preferred way for now. There are two ways I see for sharing Ant macros:
- Placing a common project in a well-known directory (typically up the directory hierarchy a bit), and then having all build files
import that file
- Using the new
antlib to define the macros, and then bringing those definitions into the current build file
I think that the metaphor I’ll use is that common build files are a part of a separate, deployable project. This approach should support:
- One central place to change the shared macros
- Easy inclusion of local common macros and targets alongside third party macros and targets
- Sharing local macros with others external to this organization
- Consistent use of the shared macros in each project without requiring per-machine or per-login configuration
To meet those needs, I’ll do the following:
- Create a separated, versioned project for common build tasks, macros, etc. whose deliverable product is a JAR file
- From the project perspective, treat the common build JAR like any other Java library, and check the JAR into that project’s version control tree
- Use a standard directory in each project to hold all
- Invoke Ant using the new
ant -lib [commonAntlibDir] [target] method
- Define namespaces at the beginning of each project file, using the
xmlns:myTasks="antlib:my.domain.ant" syntax to automagically grab the shared task from the Ant classpath that includes the local project
One challenge is that always using
ant -lib ... is bound to become tedious. Perhaps the local environment could be set to use this automatically, but that violates one of the goals. I’d prefer setting up the Ant libraries per-project rather than cluttering my local Ant installation, and hoping that everyone else has the needed libraries. This approach comes closest to doing that consistently than any other I’ve seen so far. We’ll have to see. YMMV.