bake 0.1.2 → 0.2.0

data/CHANGELOG

@@ -1,38 +0,0 @@
-= Bake Changelog
-
-== Version 0.1.2 (2007-05-17)
-
-* Implemented Target#products which returns the set of output files generated by the target
-* Using Target#products, implemented Target#stale? and Target#mtime in a general way
-* Moved C++ include file detection into IncludeList class which is now a dependency of all Cpp::Source
-* Created a Runner target class which can be used to run any commands, not just C++ executables
-* Added simple circular dependency detection during build phase
-* Implemented Target#to_s for more consistent error messages
-* Dependency resolution now uses :search_projects property to resolve unqualified target references (which always includes the current project)
-* Libraries and executables no longer re-link to changed dynamic libraries unless they are forced to by an altered header dependency
-* Target subclass initialization is now done via the post_initialization method, making the initialization methods much simpler
-* All target constructors now support a properties hash which initializes the given properties before post_initialization
-* Added Project#map method which maps target names to fully qualified dir:name paths
-* Implemented post-build dependencies which are built after their dependents are built (useful for unit tests)
-* Fixed QT Moc support
-* Trashed Configuration#req and associated "requirements" functionality as it proved not very useful
-* Major overhaul of plugin support, plugins are now searched for in any directories given in :plugin_paths
-* Moved all Ruby core class extensions into the bake/extensions directory
-* Toolsets now use a +SystemUtils+ instance for doing all file and shell operations
-* Introduced --dry-run and --verbose command line parameters
-* Dumped all the old useless unit tests (they will be re-introduced for 2.0)
-
-== Version 0.1.1 (2007-05-02)
-
-* Created a plugin infrastructure whereby missing constants now result in a search of the plugins/ directory
-* Implemented Addon module which enables adding commands to bakefile contexts via the import method
-* Removed scheme concept in favour of addon plugin classes so all concre Toolset subclasses (e.g. Cpp::Gcc) are now addon plugins
-* Context#macro and Context#glob were moved to addon classes named Macro and System respectively which are plugins that are automatically imported into bakefile contexts
-* Targets no longer found by moving up the target tree, instead all paths are relative to the current project, that is, the project owning the current target
-* Added some content to the CONCEPTS document
-* Introduced Context#using method which is similar to import, except that commands are looked up from addons stored in the :addons property of the current target
-* Removed Cpp::Library#src and Cpp::Executable#src in favor of listing file dependencies in the dep list
-* Added FileTarget class that represents simple file dependencies
-* Created Target#add_dep method that can be overridden to manage individual dependency additions (for example to insert a Cpp::Object between a FileTarget and main Cpp target)
-* Child targets are no longer considered dependencies and so are not built automatically when their parents are built
-

data/CONCEPTS

@@ -1,54 +0,0 @@
-= Concepts
-
-== Bake's Philosophy
-
-Bake is a Ruby based build system similar to Rake[http://rake.rubyforge.org] and Rant[http://rant.rubyforge.org]. Unlike either of these systems, however, there is a logical separation between the the components that are being built and the methods used to build them. This separation is important for large projects having many logical components such as executables and libraries, and also supporting many compilers or platforms.
-
-In the good old days when Make was king, adding another supported platform to a project was usually a traumatic experience. The chief reason for the difficulty was almost always that the declaration of a component and the actions executed to build that component were tightly coupled. So the structure of the project was highly dependent on the content of the actions that build it.
-
-The pitfalls of Make are readily apparent with C++ projects that support Microsoft Visual Studio and GCC. Simple projects are easy enough to accomodate in Make, but as soon as you need to support dynamic libraries and unit test runners and platform dependent build parameters you can quickly find the number of lines in your Make code outpacing the code for your project!
-
-The fundamental reason for this is that your project structure and the actions that build your project are orthogonal concepts. Make forces you to intertwine these two concepts causing your Makefiles to balloon in size. Bake, on the other hand, disentangles the target and toolset concepts and allows you to grow the set of targets and the toolsets that build them independently. This is the primary goal of the Bake project.
-
-Another goal is to provide users with a large set of pre-written toolsets that will perform the actions required to turn your project into built products. Thus, in most cases, the end user simply defines the structure of the their project, indicates which toolsets to use and Bake does the rest.
-
-The end result is that Bake requires a bare minimum of code to provide all the instructions that are needed to build a project. Furthermore, the bulk of the code defines the structure of the project rather than the behaviour of the build tools involved, so the definition files also act as a guide to the project layout, instead of being a distracting maze of complex build actions.
-
-== Targets
-
-In Bake, projects are broken up into components called *targets*. Targets are the basic unit of a project and can represent C libraries, zip files, Java classes or anything else that belongs in a project.
-
-Targets are tree-like. Each target has a single parent target and can have any number of child targets. Every target that belongs in a particular project is connected in a single tree.
-
-=== Products
-
-Every target can have a number of *products*. The products of a target are the concrete set of files that are created during the build process.
-
-=== Dependencies
-
-Targets are related to each other by two relations. The first is the parent-child relation that makes up the tree structure of a project. The other is the *dependency* relation.
-
-Before a particular target is built, there are zero or more dependencies that must be built first. If any of the dependencies fails to build, the target will fail to be built.
-
-Dependencies have two roles for a target. First, to partially determine the order in which targets will be built as outlined above. Second, their products are used by dependent targets to build its products. For example, an executable target may depend on the functionality available in a library and thus it must link against that library.
-
-=== Properties
-
-=== Requirements
-
-== Bakefiles
-
-=== Commands
-
-=== Projects
-
-== Toolsets
-
-== Features
-
-=== Macros
-
-=== Plugins
-
-=== Addins
-

data/MIT-LICENSE

@@ -1,21 +0,0 @@
-Copyright (c) 2007 Dylan Trotter
-
-Permission is hereby granted, free of charge, to any person obtaining
-a copy of this software and associated documentation files (the
-"Software"), to deal in the Software without restriction, including
-without limitation the rights to use, copy, modify, merge, publish,
-distribute, sublicense, and/or sell copies of the Software, and to
-permit persons to whom the Software is furnished to do so, subject to
-the following conditions:
-
-The above copyright notice and this permission notice shall be
-included in all copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
-EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
-MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
-NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
-LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
-OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
-WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
-

data/README

@@ -1,38 +0,0 @@
-= Bake
-
-Bake is a build automation utility somewhat akin to the Ruby tool Rake. Like Rake[http://rake.rubyforge.org/], Bake definition files (or <i>bakefiles</i>) are written in pure Ruby. The similarities between Rake and Bake pretty much end there, however. Bake generally takes a much higher level approach. Instead of defining tasks and specifying the commands that get executed by that task, you define high level products, such as C++ libraries or Java WAR files in your bakefiles. Thus bakefiles are simple, readable definitions of the final products of your project.
-
-== Download
-
-You can download the most recent version of Bake at here[http://rubyforge.org/frs/?group_id=3477]
-
-== Installation
-
-Currently, Bake only support Gem installs. Simply run:
-
-  % gem install bake
-
-If you don't like how Gems taste, it's probably not difficult to set up Bake from source. Download one of the source distributions and let me know how it works out :)
-
-== Further Reading
-
-Tutorial Introduction:: TUTORIAL[link:files/TUTORIAL.html]
-
-Concepts:: CONCEPTS[link:files/CONCEPTS.html]
-
-Reference:: REFERENCE[link:files/REFERENCE.html]
-
-== History
-
-Bake took inspiration from the many great build tools that exist out there. In particular, the idea of using Ruby as a domain specific language for build systems was pioneered Jim Weirich in his Make-like utility, Rake. After working with Rake for some time, however, I found that it was difficult to maintain large projects effectively due to the fact that Rake is quite low-level.
-
-Soon after I abandoned Rake, I found another great Ruby-based system called Rant created by Stefan Lang. Rant was slightly better and it had many great ideas for how a Ruby-based build system should work such as improved error messages, good support for larger multi-file projects, etc. I tried for a time to write Bake as extensions to Rant since I felt it a good starting point. In the end, however, it had similar limitations to Rake and I abandoned further work on Rant.
-
-On the other end of the spectrum there's {Boost.Build}[http://www.boost.org/tools/build/jam_src/index.html] which is the build system used for the {Boost C++ Libraries}[http://boost.org/]. Boost.Build does have a reasonably good project-based approach, however, the syntax is abominable. It's based on {Perforce Jam}[http://www.perforce.com/jam/jam.html] which is quite possibly the most hideous build system ever conceived. Ugly doesn't begin to describe the syntax, nor incomprehensible the so-called Jamfiles.
-
-The panacea is Bake. I think it satisfies my rather loose requirements: pretty, simple for simple projects, powerful for large projects and fast. The items in this list are at various stages in their evolution, but I think it solves my build problems better than any of the others I listed above.
-
-== License
-
-:include: MIT-LICENSE
-

data/REFERENCE

@@ -1,2 +0,0 @@
-= Reference
-

data/TUTORIAL

@@ -1,128 +0,0 @@
-= Tutorial Introduction
-
-== A C++ Executable
-
-=== Bakefiles and Targets
-
-Once you've installed Bake, you should be able to execute it by running the <tt>bake</tt> command. This will cause Bake to load a file called <i>root.bake</i> in the current working directory or some ancestor directory of the current directory. This <b>bakefile</b> defines the contents of the project including any settings required to properly make the build targets. Let's see the contents of <i>root.bake</i> for a simple C++ project consisting of a single source file, <i>main.cpp</i>, which gets compiled into an executable called <i>test</i>:
-
-  # root.bake
-  exe 'test' do
-      dep 'main.cpp'
-  end
-
-  dep 'test'
-
-The <tt>exe</tt> command specifies that we'd like to create an executable <b>target</b>. A target is any product that gets created as a result of the build process. There are many kinds of targets, such as <tt>lib</tt>s, or C++ libraries, etc. To make this example a little more concrete, let's also create <i>main.cpp</i>:
-
-  // main.cpp
-  #include <iostream>
-  int main()
-  {
-      std::cout << "hello bake" << std::endl;
-      return 0;
-  }
-
-Both these files should be in the same directory, call it <i>test/</i>. The layout is as follows:
-
-  test/
-    root.bake
-    main.cpp
-
-If you run <tt>bake</tt> from the <i>test/</i> directory you should see output resembling "<tt>root.bake:1: unknown command 'exe'</tt>". The reason for this is that we have not specified what <b>tooset</b> we will be using to build C++ targets. Bake supports a number of C++ toolsets (consult the Reference for full details) and each toolset should treat our test project identically, so which toolset you use should not matter. For the purposes of this example, I'll use the <tt>gcc</tt> toolset.
-
-=== The <tt>using</tt> Directive
-
-Generally, it is a good idea to keep your project definitions separate from which toolset you're using since your choice of toolset is conceptually distinct from your project layout. This is especially true from cross-platform projects. For this reason, in this project we'll keep this information in a separate bakefile called <i>config.bake</i> which will also live in the <i>test/</i> directory:
-
-  # config.bake
-  using Cpp::Gcc
-
-The <tt>using</tt> directive above tells Bake that when building C++ targets, it should use the <tt>gcc</tt> toolset. If you now run the <tt>bake</tt> command, and as long as your toolset is properly configured, you should get an executable file called <i>test</i> (or <i>test.exe</i> on Windows platforms) in the <i>test/</i> directory.
-
-=== Properties
-
-Unfortunately, the <i>test</i> executable will probably be accompanied by a number of by-products of the build procedure and so our <i>test/</i> directory is now getting cluttered. It is common to keep products of the build in a separate output directory so that they don't get mixed up with our source files. The output directory is just one of a number of options supported by <tt>exe</tt> targets. To specify an output directory we set the <tt>:outdir</tt> <b>property</b> on <tt>test</tt>. Properties are just key/value pairs that are used by the toolset to output the desired product. The simplest way to set a property is to use the <tt>opt</tt> command on the <tt>test</tt> target, like this:
-
-  # root.bake
-
-  exe 'test' do
-      opt :outdir => 'bin'
-      dep 'main.cpp'
-  end
-
-  dep 'test'
-
-Note that property names are <b>symbols</b> preceded by a colon (:) whereas, in this case, the property value is a <b>string</b>. Property values can be any of a number of different types such as strings, booleans, numbers, etc.
-
-Delete all the product files generated by the last build so that your directory structure looks like:
-
-  test/
-    config.bake
-    root.bake
-    main.cpp
-
-Now run Bake again. Note that a new directory called <i>bin/</i> has been created and that all the products of the build have been placed inside. C++ executable targets have a number of other properties that affect different aspects of the build. For example, to turn off multithreading for a single threaded application, you would specify "<tt>opt :multithreaded? => false</tt>". Note that we've used a boolean value type instead of a string. The type is important as a value of <tt>'false'</tt> would result in the opposite behavior we would expect (this is because strings always evaluate to true when examined in a boolean context). For a full list of target properties and their types, see the Reference.
-
-== A More Complicated Example
-
-=== Multiple Targets, One Bakefile
-
-So far we've seen Bake build a simple C++ executable, and it did the job pretty well. Bake's strengths, however, are only seen when we have more complicated projects to test it with. Bake is designed with large projects in mind and it makes managing these projects a snap.
-
-To see how Bake handles multi-directory projects, let's create a project composed of a C++ library and an executable that depends on the library. Let's try the following directory structure:
-
-  test2/
-    test_lib/
-      source1.cpp
-      source2.cpp
-    test_exe/
-      source1.cpp
-
-As a first try at managing this project, let's create a <i>root.bake</i> in the <i>test2</i> directory that contains the definitions for both <tt>test_lib</tt> and <tt>test_exe</tt>:
-
-  # root.bake
-  lib 'test_lib' do
-      dep 'test_lib/source1.cpp', 'test_lib/source2.cpp'
-  end
-
-  exe 'test_exe' do
-      dep 'test_lib', 'test_exe/source1.cpp'
-  end
-
-  dep 'test_exe'
-
-Here we have created a <tt>lib</tt> target called <tt>test_lib</tt> containing two source files, and an executable file that depends on the library and another source file. This is pretty simple and will probably seem to work, however, there's an insidious bug waiting to cause trouble when you least expect it. Note that there are two files called <i>source1.cpp</i>. In each case, a C++ object file called <i>source1.o</i> (or <i>source1.obj</i> on Windows) will be created in the <i>test2/</i> directory, the object file from <tt>test_exe</tt> will overwrite the object file from <tt>test_lib</tt>. This will not immediately cause a problem, since the library object file was added to the library before the executable object file was created but it will almost certainly cause problems later on.
-
-=== More About Properties
-
-The easiest way to avoid conflicts where output files overwrite eachother is to set the <tt>:outdir</tt> property differently on each target so that the object files will live in different directories. To do this, however, we're going to take a shortcut and only set the output directory once:
-
-  # root.bake
-  opt :outdir => 'bin/${name}'
-  lib 'test_lib' do
-      opt :name => 'test_lib'
-      dep 'test_lib/source1.cpp', 'test_lib/source2.cpp'
-  end
-
-  exe 'test_exe' do
-      opt :name => 'test_exe'
-      dep 'test_lib', 'test_exe/source1.cpp'
-  end
-
-  dep 'test_exe'
-
-If you run Bake now, the outputs from <tt>test_lib</tt> will end up in <i>test2/bin/test_lib/</i> and the outputs from <tt>test_exe</tt> will end up in <i>test2/bin/test_exe</i>. If you're confused, don't worry, we've taken two steps forward here. Not only is the value of the <tt>:outdir</tt> property not explicitly set on either target, but it's out in no-man's land, what gives? Furthermore, what's up with the <tt>${name}</tt> business?
-
-The answer to the first question is related to an important fact about targets: they are tree-like. Every target (except the root target, which we'll get into later) has a single parent target, and many targets have child targets. So what target is the parent of <tt>test_lib</tt> and <tt>test_exe</tt>? An implicit <b>project</b> target that is created when <i>root.bake</i> is processed. Therefore, the <tt>opt</tt> command is being executed on the implicit project target and so <tt>:outdir</tt> is set for the project.
-
-Furthermore, properties are inherited. So if a property is explicitly defined for a parent target but is not explicitly defined for the child, then the property for the child is the same as that for the parent. Properties can be overridden by explicitly using the <tt>opt</tt> command on the child, in which case the parent's property value will be ignored.
-
-So in the example above, the <tt>:outdir</tt> property is inherited by the <tt>test_lib</tt> and <tt>test_exe</tt> targets as <tt>'bin/${name}'</tt>.
-
-The answer to the second question is even simpler. String property values are dynamic. Any <tt>${...}</tt> tokens found in the string will be evaluated when the property is queried. In addition, it will be queried in the context of the target being queried, not the target where the property was originally defined. So when the GCC toolset builds <tt>test_lib</tt> and <tt>test_exe</tt>, it will query the <tt>:outdir</tt> property on each target and it will evaluate to <tt>'bin/test_lib'</tt> and <tt>'bin/test_exe'</tt> respectively since we've defined the <tt>:name</tt> property for each appropriately.
-
-=== Modular Bakefiles
-
-TODO
-

data/lib/bake/addon.rb

@@ -1,20 +0,0 @@
-module Bake
-    module Addon
-        def command(name, method = nil, &block)
-            if !block
-                method ||= name
-                addon = self
-                block = Proc.new do |*args|
-                    block = args.last.is_a?(Proc) ? args.pop : nil
-                    addon.send(method, self, *args, &block)
-                end
-            end
-            commands[name] = block
-        end
-
-        def commands
-            return @commands ||= { }
-        end
-    end
-end
-

data/lib/bake/configuration.rb

@@ -1,126 +0,0 @@
-module Bake
-    class PropertyNotFoundException < RuntimeError; end
-    class TemplateEvaluationException < RuntimeError; end
-
-    module Configuration
-        def has_prop?(key)
-            cfg = self
-            while cfg
-                return true if cfg.has_prop_impl(key)
-                cfg = cfg.parent
-            end
-            return false
-        end
-
-        def [](key)
-            return get(key)
-        end
-
-        def get(key)
-            if multival(key)
-                cfg = self
-                opts = []
-                while cfg
-                    if cfg.options.has_key?(key)
-                        cfg.options[key].each { |val| opts << value_of(val) }
-                    end
-                    cfg = cfg.parent
-                end
-                return opts
-            else
-                cfg = self
-                default = nil
-                found_default = false
-                while cfg
-                    if cfg.options.has_key?(key)
-                        return value_of(cfg.options[key])
-                    end
-                    if !found_default && cfg.defaults.has_key?(key)
-                        default = cfg.defaults[key]
-                        found_default = true
-                    end
-                    cfg = cfg.parent
-                end
-                if found_default
-                    val = value_of(default)
-                    return val
-                end
-                raise PropertyNotFoundException, "no such property '#{key}'"
-            end
-        end
-
-        def is?(prop)
-            key, val = key_val(prop)
-            raise 'no multivalue comparisons' if multival(key)
-            begin
-                return get(key) == val
-            rescue PropertyNotFoundException
-                return false
-            end
-        end
-
-        def opt(prop)
-            key, val = key_val(prop)
-            if multival(key)
-                vals = options[key] ||= []
-                if val.respond_to?(:to_ary)
-                    vals.concat(val)
-                else
-                    vals << val
-                end
-            else
-                options[key] = val
-            end
-        end
-
-        def default(prop)
-            key, val = key_val(prop)
-            raise 'no multivalue defaults' if multival(key)
-            defaults[key] = val
-        end
-
-    protected
-        def options
-            return @options ||= {}
-        end
-
-        def defaults
-            return @defaults ||= {}
-        end
-
-        def has_prop_impl(key)
-            return options.has_key?(key) ||
-                defaults.has_key?(key)
-        end
-
-        def key_val(prop)
-            raise 'invalid args' if !prop.respond_to?(:to_hash)
-            prop = prop.to_hash
-            raise 'bad' if prop.size != 1
-            key = prop.keys[0]
-            return [ key, prop[key] ]
-        end
-
-        def multival(key)
-            return key.to_s[-1, 1] == 's'
-        end
-
-        def value_of(val)
-            if val.instance_of?(String)
-                return val.gsub(/\$\{(.*?)\}/) do
-                    name = $1
-                    if has_prop?(name.to_sym)
-                        get(name.to_sym)
-                    elsif ENV.has_key?(name)
-                        ENV[name]
-                    else
-                        raise TemplateEvaluationException,
-                            "no property or environment variable '#{name}'"
-                    end
-                end
-            end
-            return val
-        end
-    end
-end
-

data/lib/bake/extensions.rb

@@ -1,3 +0,0 @@
-Dir[File.join(File.dirname(__FILE__), 'extensions', '*.rb')].each do |file|
-    require 'bake/extensions/' + File.basename(file, '.rb')
-end

data/lib/bake/extensions/class.rb

@@ -1,11 +0,0 @@
-class Class
-    # Returns true if +self+ inherits from +ancestor+
-    def inherits?(ancestor)
-        sup = self
-        while sup
-            return true if sup.equal?(ancestor)
-            sup = sup.superclass
-        end
-        return false
-    end
-end