<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.comp.lang.ruby.rake">
    <title>gmane.comp.lang.ruby.rake</title>
    <link>http://blog.gmane.org/gmane.comp.lang.ruby.rake</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.ruby.rake/708"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.ruby.rake/707"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.ruby.rake/695"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.ruby.rake/693"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.ruby.rake/692"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.ruby.rake/691"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.ruby.rake/690"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.ruby.rake/682"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.ruby.rake/676"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.ruby.rake/675"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.ruby.rake/671"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.ruby.rake/662"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.ruby.rake/661"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.ruby.rake/660"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.ruby.rake/659"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.ruby.rake/652"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.ruby.rake/651"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.ruby.rake/645"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.ruby.rake/640"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.ruby.rake/637"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.ruby.rake/708">
    <title>Overloading the divide symbol on String to facilitate path concatenation?</title>
    <link>http://comments.gmane.org/gmane.comp.lang.ruby.rake/708</link>
    <description>&lt;pre&gt;Hello fellow rake developers,

I started using this construction in my rake files and I wanted to get your opinion on it (though if there is a better forum, please direct me there).


Problem
-------

In my rake scripts, I like to assign directory paths to variables so I can use the variables later in my program. The problem is, when concatenating the variables, I end up with ugly combinations like:

  File.join(BUILD_D, "bin", "x86")
  File.join(CACHE_D, "scripts", SCRIPT_TEMP_NAME)


Possible Solution
-----------------

I find this hard to read so I tried something:

  class String
  
    def /(path)
      if !path
        self
      else
        File.join(self, path)
      end
    end
  
  end

Now I can make paths like:

  BUILD_D/"bin"/"x86"
  CACHE_D/"scripts"/SCRIPT_TEMP_NAME


Discussion
----------

My spidey sense is on overload from former C++ days where I was filled with "operator overloading is bad. Always. Never ever do it. Ever... ever"

But I have to say, the more I use this, the more I like i&lt;/pre&gt;</description>
    <dc:creator>Michael Bishop</dc:creator>
    <dc:date>2012-04-30T19:00:12</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.ruby.rake/707">
    <title>ANN: (yet another) version of -j implementation (includes -m for multitask)</title>
    <link>http://comments.gmane.org/gmane.comp.lang.ruby.rake/707</link>
    <description>&lt;pre&gt;Hello Everyone,

My last implementation of -j had a fatal flaw which could have led to stack overflow for large amounts of tasks. I discovered this after prototyping a version with drake's feature of turning tasks into multitasks.

I have a new version with a rewritten MultiTask implementation which removes that flaw, is smaller, and easily fits into Rake code. In addition, I've added an optional "--multitask -m" flag to turn every task into a multitask (in direct homage to drake).

   https://github.com/michaeljbishop/rake

I've again added a pull-request for the inclusion of the change to the master branch (as always allowing for further changes to match the style and simplicity of the original)

  https://github.com/jimweirich/rake/pull/113

Questions and comments as always, are welcome.

Sincerely,

Michael Bishop


---


## PROBLEM SUMMARY (THE CASE FOR -j and -m)

Rake can be unusable for builds invoking large numbers of concurrent external processes.

## PROBLEM DESCRIPTION

Rake makes it easy to maxi&lt;/pre&gt;</description>
    <dc:creator>Michael Bishop</dc:creator>
    <dc:date>2012-04-27T13:54:53</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.ruby.rake/695">
    <title>Announcement: Alternate -j implementation</title>
    <link>http://comments.gmane.org/gmane.comp.lang.ruby.rake/695</link>
    <description>&lt;pre&gt;Hello Everyone,

I've recently finished an implementation of -j &amp;lt;max_concurrent_jobs&amp;gt; and would be delighted if the members of this list would take a detailed look at it

It's in this rake branch on github:

   https://github.com/michaeljbishop/rake/commit/295c7a4d6d58b3e10c27b940a8259dd3e01c52f0
 or
   http://bit.ly/JMVARy

In addition, I've added a pull-request for the inclusion of the change to the master branch (allowing of course for further changes to match the style and simplicity of the original)

 https://github.com/jimweirich/rake/pull/112

My apologies if this has been hashed out many times on this list. I'm hoping to offer a fresh look at the problem. Thank you for your consideration.

Sincerely,

Michael Bishop


---


SUMMARY
-------

USER INTERFACE:

The user-interface is simply a new -j flag that specifies the maximum number of tasks that can execute simultaneously (discussed here before as I've seen). If the -j flag is omitted, the old behavior of unlimited concurrent tasks is retained.


IM&lt;/pre&gt;</description>
    <dc:creator>Michael Bishop</dc:creator>
    <dc:date>2012-04-19T11:36:37</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.ruby.rake/693">
    <title>Merging drake and rake?</title>
    <link>http://comments.gmane.org/gmane.comp.lang.ruby.rake/693</link>
    <description>&lt;pre&gt;Hi,

Are there any plans to merge drake's features back into rake?

Jos
&lt;/pre&gt;</description>
    <dc:creator>Jos Backus</dc:creator>
    <dc:date>2011-09-17T05:39:04</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.ruby.rake/692">
    <title>No longer able to run Rake tests due fork() usage</title>
    <link>http://comments.gmane.org/gmane.comp.lang.ruby.rake/692</link>
    <description>&lt;pre&gt;Hello,

I guess the subject explain it completely, but I'm not able to run
Rake tests anymore due fork usage in them.

This not only affects Windows but also JRuby.

I know this is related to session gem removal, but was wondering if
there isn't another workaround?

Thank you.
&lt;/pre&gt;</description>
    <dc:creator>Luis Lavena</dc:creator>
    <dc:date>2011-08-16T17:03:08</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.ruby.rake/691">
    <title>Beta 1 for Rake 0.9.3 is out</title>
    <link>http://comments.gmane.org/gmane.comp.lang.ruby.rake/691</link>
    <description>&lt;pre&gt;I've pushed a beta version of 0.9.3 out to Rubygems.org.  

Here is the change list.

* The rake test loader now removes arguments it has processed.  Issue #51
* Rake::TaskArguments now responds to #values_at
* RakeFileUtils.verbose_flag = nil silences output the same as 0.8.7
* Rake tests are now directory-independent
* Rake tests are no longer require flexmock
* Commands constant is no longer polluting top level namespace.
* Show only the interesting portion of the backtrace by default (James M. Lawrence).
* Added --reduce-compat optiont to remove backward compatible DSL hacks (James M. Lawrence).

The rake tests task pattern issue isn't explicitly mentioned here, but it seems to be resolved.  Eric, I'm assuming you did something to fix that (cf. https://github.com/jimweirich/rake/issues/51)

Anyways, grab the beta and give it a spin and report back if there are issues.

Thanks.

&lt;/pre&gt;</description>
    <dc:creator>Jim Weirich</dc:creator>
    <dc:date>2011-08-06T03:05:45</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.ruby.rake/690">
    <title>3 Failures at master (a774ef8)</title>
    <link>http://comments.gmane.org/gmane.comp.lang.ruby.rake/690</link>
    <description>&lt;pre&gt;Hello,

I'm getting the following failures running against 1.8.7, 1.9.2 and trunk:

  1) Failure:
test_directory_win32(TestRakeDirectoryTask)
[C:/Users/Luis/Projects/oss/jimweirich/rake/test/test_rake_directory_task.rb:32]:
Expected Rake::FileCreationTask, not Rake::FileTask.

  2) Failure:
test_egrep_with_output(TestRakeFileList)
[C:/Users/Luis/Projects/oss/jimweirich/rake/test/test_rake_file_list.rb:345]:
Expected "xyzzy.txt:2:XYZZY", not "xyzzy.txt:2:XYZZY\r\n".

  3) Failure:
test_egrep_with_block(TestRakeFileList)
[C:/Users/Luis/Projects/oss/jimweirich/rake/test/test_rake_file_list.rb:356]:
Expected ["xyzzy.txt", 2, "XYZZY\n"], not ["xyzzy.txt", 2, "XYZZY\r\n"].

Is worth mentioning that I'm using Windows :-)

Seems to me that #2 and #3 are related to newlines output in the
console, perhaps there is another way to verify the output
independently of LF/CR?

&lt;/pre&gt;</description>
    <dc:creator>Luis Lavena</dc:creator>
    <dc:date>2011-06-23T23:37:33</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.ruby.rake/682">
    <title>Rake 0.9.0.beta.5 is out</title>
    <link>http://comments.gmane.org/gmane.comp.lang.ruby.rake/682</link>
    <description>&lt;pre&gt;No big functionality changes in this one, just cleaning up some of the cruft leftover from the namespacing experiment. I expect this version to become 0.9.0 final unless someone discovers a big problem.

&lt;/pre&gt;</description>
    <dc:creator>Jim Weirich</dc:creator>
    <dc:date>2011-03-14T01:24:13</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.ruby.rake/676">
    <title>Environment changes in the beta</title>
    <link>http://comments.gmane.org/gmane.comp.lang.ruby.rake/676</link>
    <description>&lt;pre&gt;% cat mystuff.rb
module MyStuff
  CONST_B = 44
end

% cat Rakefile
require 'rake'
require './mystuff'

module MyStuff
  CONST_A = 33
end

p MyStuff::CONST_A
p MyStuff::CONST_B
# =&amp;gt; uninitialized constant Rake::Environment::MyStuff::CONST_B

task :default

% rake --version
rake, version 0.9.0.beta.1

% rake
33
rake aborted!
uninitialized constant Rake::Environment::MyStuff::CONST_B

Writing ::MyStuff::CONST_B instead works, and conversely
::MyStuff::CONST_A is an error.

It seems that Rake::DSL already provides the necessary partitioning.
If I wanted to keep the global scope clean, I would do

module MyStuff
  extend Rake::DSL

  task :default do
    # ...
  end
end

Could an example like that in the README replace the need for
environment.rb?
&lt;/pre&gt;</description>
    <dc:creator>James M. Lawrence</dc:creator>
    <dc:date>2011-03-02T03:55:18</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.ruby.rake/675">
    <title>New Beta Version of Rake</title>
    <link>http://comments.gmane.org/gmane.comp.lang.ruby.rake/675</link>
    <description>&lt;pre&gt;A new beta version of Rake is out (0.9.0.beta.1) and is ready for folks to kick the tires.  It's been a while since the last release and with Eric's help we've been whipping this into shape.

Install with:   gem install rake --pre

The CHANGES file should have all the details.

&lt;/pre&gt;</description>
    <dc:creator>Jim Weirich</dc:creator>
    <dc:date>2011-02-28T12:46:28</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.ruby.rake/671">
    <title>About that new magic comment ...</title>
    <link>http://comments.gmane.org/gmane.comp.lang.ruby.rake/671</link>
    <description>&lt;pre&gt;Assume the following tasks were written for Rake 0.8.x.

  # This comment describes a non-toplevel-task.
  task :complex_task do
    # ...
  end

  # For internal use only -- washes laundry, takes out trash, other
  # crap.
  task :house do
    # ...
  end

  #
  # I prefer this comment style.
  #
  task :style do
    # ...
  end

#### output of rake --tasks:

  rake complex_task  # This comment describes a non-toplevel-task.
  rake house         # crap.

Fortunately my own commenting style avoids this problem. Others will
likely encounter some annoyance (small or possibly great).

One could make the comment-grabber smarter, but the question is: How
should a programmer document a top-level task? There is already an API
method for doing so: desc. The new comment-to-desc feature does not
solve an actual problem or deficiency.

There could hundreds of these new magic-comment 'desc's cropping up,
making the --tasks output useless. Even one newly-public comment could
be an issue (think of a programmer making a ve&lt;/pre&gt;</description>
    <dc:creator>James M. Lawrence</dc:creator>
    <dc:date>2011-02-28T04:10:02</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.ruby.rake/662">
    <title>Task for nested instance of Rake</title>
    <link>http://comments.gmane.org/gmane.comp.lang.ruby.rake/662</link>
    <description>&lt;pre&gt;Hi.

I'm a .NET developer. I recently decided to use Rake to handle things
such as deployment and database management for my .NET projects.
The projects are still build using MSBuild cause of Visual Studio (VS).

One problem I continually encounter is that there is no natural way to
order dependent projects using Rake. 
I'll give an example: In .NET it is quite natural to order projects in a
nested structure with a master project that have a number of
sub-projects in a hierarchical structure (as shown below). 

C:\Projects\Project1\master vs file
C:\Projects\Project1\Rakefile.rb
C:\Projects\Project1\... (master project files)

C:\Projects\Project1\SubProject1\sub1 vs file
C:\Projects\Project1\SubProject1\Rakefile.rb
C:\Projects\Project1\SubProject1\... (sub1 project files)

C:\Projects\Project1\SubProject2\sub 2 vs file
C:\Projects\Project1\SubProject2\Rakefile.rb
C:\Projects\Project1\SubProject2\... (sub2 project files)
...

Now if you for any reason have an interest in separating the
sub-projects from the &lt;/pre&gt;</description>
    <dc:creator>Jesper Tholstrup Pedersen (JUP</dc:creator>
    <dc:date>2011-02-22T08:39:17</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.ruby.rake/661">
    <title>Parameter not task key?</title>
    <link>http://comments.gmane.org/gmane.comp.lang.ruby.rake/661</link>
    <description>&lt;pre&gt;Hello,
I'm currently trying to build an existing C++ project with rake. I want to build different "flavors" (debug, release, etc.) of the software. Every flavor uses it's own output directory, so the different flavors can live in parallel. To pass the flavor to rake, I use the task parameter. The tasks are build automatically from the existing source directory structure. What puzzled me  a little bit is, that the parameter isn't part of the key (or name) of a task. When I try to build two different flavors of the same task, the task gets executed once, not twice as I've thought it should be. Example:

rake libs[debug] libs[release]

Is this intended behavior or should I fill a bug-report / feature-request?

best regards
Torsten

btw: Thanks for the wonderful tool (rake) 
&lt;/pre&gt;</description>
    <dc:creator>Torsten&lt; at &gt;Robitzki.de</dc:creator>
    <dc:date>2011-02-20T12:19:22</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.ruby.rake/660">
    <title>rake check_manifest deletes my doc Directory</title>
    <link>http://comments.gmane.org/gmane.comp.lang.ruby.rake/660</link>
    <description>&lt;pre&gt;Hi

I am using rake for a lot of our web projects. Those project all have
a _doc_ directory.

Now if I go by the books and run

rake check_manifest

my doc directory is wiped away. That is sad and not so userfriendly.

Any hints how I could prevent that?

Thank you for your Feedback.

Best
Zeno
&lt;/pre&gt;</description>
    <dc:creator>Zeno Davatz</dc:creator>
    <dc:date>2011-02-11T15:52:26</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.ruby.rake/659">
    <title>Adding usage data gathering functionality to rake</title>
    <link>http://comments.gmane.org/gmane.comp.lang.ruby.rake/659</link>
    <description>&lt;pre&gt;I've posted this in the github issue tracker 
(https://github.com/jimweirich/rake/issues/#issue/21).
Here's hoping this list s still active, since I was only able to find 
archives till June last year.

I'm experimenting with gathering usage data from rakefiles.
Primarily I would like to know which task was called, its dependency 
chain and the time execution took (ideally total time and time per task).

I thought that if rake provided this out of the box it would be extra 
convenient (using a profiler I have to aggregate method calls, time only 
works on *x platforms etc.) and would provide the right level of 
granularity.

I've done a quick proof of concept (it's linked in the comments of the 
issue).
Any thoughts?
V.-

&lt;/pre&gt;</description>
    <dc:creator>Vassilis Rizopoulos</dc:creator>
    <dc:date>2011-01-25T06:15:48</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.ruby.rake/652">
    <title>New loading behavior</title>
    <link>http://comments.gmane.org/gmane.comp.lang.ruby.rake/652</link>
    <description>&lt;pre&gt;task :default do
end

extra = "Rakefile.extra"
File.open(extra, "w") { |f| f.puts "p SPEC" }
SPEC = 99

# OK in rake-0.8.7; error in rake-0.8.99 (uninitialized constant SPEC)
load extra

# OK in rake-0.8.99; error in rake-0.8.7 (load_rakefile not present)
load_rakefile extra

Is this the expected behavior?
&lt;/pre&gt;</description>
    <dc:creator>James M. Lawrence</dc:creator>
    <dc:date>2010-06-07T16:26:42</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.ruby.rake/651">
    <title>A handful of issues</title>
    <link>http://comments.gmane.org/gmane.comp.lang.ruby.rake/651</link>
    <description>&lt;pre&gt;==== 1 - Task#needed? applies to immediate prereqs only

file "a" =&amp;gt; "b" do
  touch "a"
end

file "b" =&amp;gt; "c" do
  touch "b"
end

file "c" do
  touch "c"
end

task :default do
  touch ["a", "b"]
  sleep 1
  touch "c"
  p Rake::Task["a"].needed?  # =&amp;gt; false
  # ... but "a" is needed because "c" is newer
end

==== 2 - Task#needed? can be wrong even for immediate prereqs

file "a" =&amp;gt; "b" do
  touch "a"
end

file "b" do
  touch "b"
end

task :default do
  touch "a"
  rm_f "b"
  p Rake::Task["a"].needed?  # =&amp;gt; false
  # ... but "a" is needed because "b" will be newly created
end

==== 3 - Filesystem timestamp granularity

memo = []

file "a" =&amp;gt; "b" do
  memo &amp;lt;&amp;lt; "a"
  touch "a"
end

file "b" do
  memo &amp;lt;&amp;lt; "b"
  touch "b"
end

task :default do
  touch "a"
  rm_f "b"
  Rake::Task["a"].invoke
  p memo # =&amp;gt; ["b"]
  # ... but should be ["b", "a"] since "b" is newer
end

==== 4 - Dependency relation should be transitive

memo = []

file "a" =&amp;gt; "b" do
  memo &amp;lt;&amp;lt; "a"
  touch "a"
end

file "b" =&amp;gt; "c" do
  memo &amp;lt;&amp;lt; "b"
  # does&lt;/pre&gt;</description>
    <dc:creator>James M. Lawrence</dc:creator>
    <dc:date>2010-06-07T07:03:29</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.ruby.rake/645">
    <title>Rake 0.8.7 broken on Windows</title>
    <link>http://comments.gmane.org/gmane.comp.lang.ruby.rake/645</link>
    <description>&lt;pre&gt;Hi all,

In Rake::AltSystem#repair_command, you're now appending "call " to the
beginning of the command.  This has the effect of losing the working
directory.  For example, running 'rake test' from the root directory of
a project will fail to find its unit tests.  It also causes a lot of gem
installation failures, as 'gem install' often seems to run rake from the
installed gem directory to complete the installation, and fails to find
necessary files.

This is not backward compatible, obviously.

1 - Is there a workaround?

2 - Why is the 'call' necessary?  Is this part of preserving the linux
'sh' semantics you mentioned?  If so, how would one avoid this problem
in linux?

Thanks,

Brian Hartin
&lt;/pre&gt;</description>
    <dc:creator>Hartin, Brian</dc:creator>
    <dc:date>2010-05-26T20:42:29</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.ruby.rake/640">
    <title>Comments about parallel building</title>
    <link>http://comments.gmane.org/gmane.comp.lang.ruby.rake/640</link>
    <description>&lt;pre&gt;For our project one of the top goals was minimizing build times; so 
being able to invoke compilers/linkers in parallel to take advantage of 
multiple-core computers was a necessity.

(Since finishing my implementation, I have learned about drake. I intend 
to take a look at that as a possible alternative approach.)

The user specifies "j=N" on the command line, similar to make's -jN. 
When N&amp;gt;1, tasks are created as MultiTasks. Since FileTasks aren't 
MultiTasks, when there's a library or application, a MultiTask is 
created that has all the object files as prerequisistes; then the 
library/app includes that MultiTask in its prerequisites. This allows 
the object files to compile in parallel.

Since MultiTasks run all their prereqs at the same time, I made a custom 
version of the 'sh' method which synchronizes using a semaphore; that 
semaphore is initialized with the j=N value that the user specified. 
That way, only N commands will be invoked at once.

Recently, I tried updating to ruby 1.9.1. My MultiTas&lt;/pre&gt;</description>
    <dc:creator>Heath Kehoe</dc:creator>
    <dc:date>2010-05-19T18:00:53</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.ruby.rake/637">
    <title>Comments from a new rake user</title>
    <link>http://comments.gmane.org/gmane.comp.lang.ruby.rake/637</link>
    <description>&lt;pre&gt;Hello all,

I have recently implemented a build system based on Rake for a 
decently-sized project (~8000 source files) which builds code and data 
for several libraries and applications targeting four separate platforms.

I was new to both rake and ruby when I started; and it's a testament to 
the awesomeness of both that I was able to learn them quickly to be able 
to implement a fairly complicated system in less than a month.

Anyway, I wanted to pass along some comments.

Firstly, when I first got stuff building with rake (replacing a build 
environment that used gnu make) I noticed that a null build (where 
everything was up to date) took a really long time. I used the ruby 
profiler and found that approx. half the run time was spent doing file 
stats (exist? and mtime), with an average of 70 calls *per file* during 
a rake run. As it runs under Cygwin on Windows those file stat 
operations are more expensive than they are on Linux. I should note that 
I'm using ruby 1.8.7 and the rake that gem installe&lt;/pre&gt;</description>
    <dc:creator>Heath Kehoe</dc:creator>
    <dc:date>2010-05-19T17:13:55</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.ruby.rake/636">
    <title>Add path ( Pathname to file tasks)</title>
    <link>http://comments.gmane.org/gmane.comp.lang.ruby.rake/636</link>
    <description>&lt;pre&gt;_______________________________________________
Rake-devel mailing list
Rake-devel&amp;lt; at &amp;gt;rubyforge.org
http://rubyforge.org/mailman/listinfo/rake-devel&lt;/pre&gt;</description>
    <dc:creator>Dominic Sisneros</dc:creator>
    <dc:date>2010-05-18T23:15:16</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.lang.ruby.rake">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.lang.ruby.rake</link>
  </textinput>
</rdf:RDF>

