From t_leitner at gmx.at  Tue Jan  2 15:22:32 2007
From: t_leitner at gmx.at (Thomas Leitner)
Date: Tue, 2 Jan 2007 21:22:32 +0100
Subject: [Rake-devel] Bug: rake clean removes core directory
Message-ID: <20070102212232.4b3b7a5b@localhost>

Hi,

I happen to have a directory called doc/src/documentation/plugins/core
in my project directory and I manage my project with rake.

As I did a "rake clobber" I saw that the core directory was removed!
Fortunately, I use svn which did its job very well! :-)

However, I think that only core files should be removed, and not core
directories! I know too little of Rake::FileList and the internals
of rake to have a patch ready.

The bug seems to be originating from lib/rake/clean.rb

  CLEAN = Rake::FileList["**/*~", "**/*.bak", "**/core"]

After excluding the doc/src/documentation/plugins/core from the CLEAN
variable, the directory was not deleted anymore.

Bye,
  Thomas

From jim at weirichhouse.org  Tue Jan  2 20:03:18 2007
From: jim at weirichhouse.org (Jim Weirich)
Date: Tue, 02 Jan 2007 20:03:18 -0500
Subject: [Rake-devel] Bug: rake clean removes core directory
In-Reply-To: <20070102212232.4b3b7a5b@localhost>
References: <20070102212232.4b3b7a5b@localhost>
Message-ID: <459B00D6.5090400@weirichhouse.org>

Thomas Leitner wrote:
 > I happen to have a directory called doc/src/documentation/plugins/core
 > in my project directory and I manage my project with rake.
 >
 > As I did a "rake clobber" I saw that the core directory was removed!
 > Fortunately, I use svn which did its job very well! :-)

Ouch! The intent is to remove core dump files. I'll look into a
better way of handling this.

-- Jim Weirich

From shea08 at eastlink.ca  Wed Jan 10 15:52:26 2007
From: shea08 at eastlink.ca (Shea Martin)
Date: Wed, 10 Jan 2007 16:52:26 -0400
Subject: [Rake-devel] adding targets
Message-ID: <eo3jme$qc0$1@sea.gmane.org>

I have a rakefile which takes a C++ source tree, and creates objects 
elsewhere.

i.e., source/dir/file.cpp compiles to build/dir/file.o.  I created a 
rule for this, and all works well.

Often it is handy to compile a single file based on just the source 
path, without wanting to resolve what the object file will be.  (i.e, 
from Vim, calling 'rake expand("%")' ).

So I created a task like this:

task :singleobj do |t|
	src = ENV['srcfile']
	obj = src.pathmap( "%{^source,build}.o" )
	sh( "rake #{obj}" )
end

This allows me to issue the command from Vim
'rake singleobj srcfile=source/dir/file.cpp'

This is good, but the rake command is called twice.  Is there a way I 
can avoid calling rake recursively?

Thanks,

~S


From shea08 at eastlink.ca  Wed Jan 10 16:14:53 2007
From: shea08 at eastlink.ca (Shea Martin)
Date: Wed, 10 Jan 2007 17:14:53 -0400
Subject: [Rake-devel] adding targets
In-Reply-To: <eo3jme$qc0$1@sea.gmane.org>
References: <eo3jme$qc0$1@sea.gmane.org>
Message-ID: <eo3l0e$v3b$1@sea.gmane.org>

> This allows me to issue the command from Vim
> 'rake singleobj srcfile=source/dir/file.cpp'
I meant
'rake singleobj srcfile=expand("%")'

as expand evaluates to the name of teh current file in Vim.

~S


From zach.dennis at gmail.com  Sat Jan 13 18:22:03 2007
From: zach.dennis at gmail.com (Zach Dennis)
Date: Sat, 13 Jan 2007 18:22:03 -0500
Subject: [Rake-devel] adding targets
In-Reply-To: <eo3l0e$v3b$1@sea.gmane.org>
References: <eo3jme$qc0$1@sea.gmane.org> <eo3l0e$v3b$1@sea.gmane.org>
Message-ID: <85d99afe0701131522n5e4b78e8mf2b08e9f8f8ac6b@mail.gmail.com>

If you have a task which builds/compiles your file(s) you can just
call that within rake.

ie:
    Rake::Task['compile'].invoke

This saves you from having to re-execute rake.

Zach





On 1/10/07, Shea Martin <shea08 at eastlink.ca> wrote:
> > This allows me to issue the command from Vim
> > 'rake singleobj srcfile=source/dir/file.cpp'
> I meant
> 'rake singleobj srcfile=expand("%")'
>
> as expand evaluates to the name of teh current file in Vim.
>
> ~S
>
> _______________________________________________
> Rake-devel mailing list
> Rake-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rake-devel
>

From shea08 at eastlink.ca  Sun Jan 14 15:14:15 2007
From: shea08 at eastlink.ca (Shea Martin)
Date: Sun, 14 Jan 2007 16:14:15 -0400
Subject: [Rake-devel] adding targets
In-Reply-To: <85d99afe0701131522n5e4b78e8mf2b08e9f8f8ac6b@mail.gmail.com>
References: <eo3jme$qc0$1@sea.gmane.org> <eo3l0e$v3b$1@sea.gmane.org>
	<85d99afe0701131522n5e4b78e8mf2b08e9f8f8ac6b@mail.gmail.com>
Message-ID: <eoe2ud$506$1@sea.gmane.org>

> ie:
>     Rake::Task['compile'].invoke
> 
> This saves you from having to re-execute rake.
> 

Exactly what I wanted.  Thanks.
~S


From shea08 at eastlink.ca  Wed Jan 17 09:44:45 2007
From: shea08 at eastlink.ca (Shea Martin)
Date: Wed, 17 Jan 2007 10:44:45 -0400
Subject: [Rake-devel] problem importing deps
Message-ID: <eolcou$v43$1@sea.gmane.org>

My source tree looks like this.

source/dir/file1.cpp
source/dir/file1.h
source/another_dir/file2.cpp
source/another_dir/file2.h

I build to a build directory, which afeter a build looks like this:
build/dir/file1.o
build/another_dir/file2.o
build/another_dir/file2.mf

my .cpp.o rule looks like this:
rule '.o' => [ proc { |target| target.pathmap( 
"%{^#{$config.builddir},#{$config.srcdir}}X.c" ) } ] do | task |
    sh( "gcc -c -o #{task.name} #{task.source}
    sh( "gcc -MM -o #{task.name.ext('.mf')} #{task.source}" )
end

I import the .mf files using 'import'.

Note: rake fails to import the dep files if I name them anything other 
than .mf.  It is pretty common practise to name these files .d, but rake 
chokes on them then, assuming they are ruby files...

build/dir/file1.mf would look like this:
file1.o: source/dir/file1.h source/another_dir.h c:/path/to/API/hdr.h

rake -P then shows the deps like this:
file1.o as "source/dir/file1.h source/another_dir.h c"

So the import is choking on the colon in the path of hdr.h.  This is the 
first problem. I can work around it by filtering the absolute paths out 
of the .mf file, as I really don't want to do dep checking on files out 
of my local tree anyway.

The second problem is that when I build a file I do it like this:
rake build/dir/file1.o.  The dep checking is never done because the .mf 
file is specifies file.o not build/dir/file.o.  I am not sure what to do 
about this one...

It looks like I may be better just to write my own dep checking tool...

Thought, tips?

~S


From shea08 at eastlink.ca  Wed Jan 17 16:51:25 2007
From: shea08 at eastlink.ca (Shea Martin)
Date: Wed, 17 Jan 2007 17:51:25 -0400
Subject: [Rake-devel] problem importing deps
In-Reply-To: <eolcou$v43$1@sea.gmane.org>
References: <eolcou$v43$1@sea.gmane.org>
Message-ID: <eom5ou$4ov$1@sea.gmane.org>

Shea Martin wrote:
> My source tree looks like this.
> 
> source/dir/file1.cpp
> source/dir/file1.h
> source/another_dir/file2.cpp
> source/another_dir/file2.h
> 
> I build to a build directory, which afeter a build looks like this:
> build/dir/file1.o
> build/another_dir/file2.o
> build/another_dir/file2.mf
> 
> my .cpp.o rule looks like this:
> rule '.o' => [ proc { |target| target.pathmap( 
> "%{^#{$config.builddir},#{$config.srcdir}}X.c" ) } ] do | task |
>     sh( "gcc -c -o #{task.name} #{task.source}
>     sh( "gcc -MM -o #{task.name.ext('.mf')} #{task.source}" )
> end
> 
> I import the .mf files using 'import'.
> 
> Note: rake fails to import the dep files if I name them anything other 
> than .mf.  It is pretty common practise to name these files .d, but rake 
> chokes on them then, assuming they are ruby files...
> 
> build/dir/file1.mf would look like this:
> file1.o: source/dir/file1.h source/another_dir.h c:/path/to/API/hdr.h
> 
> rake -P then shows the deps like this:
> file1.o as "source/dir/file1.h source/another_dir.h c"
> 
> So the import is choking on the colon in the path of hdr.h.  This is the 
> first problem. I can work around it by filtering the absolute paths out 
> of the .mf file, as I really don't want to do dep checking on files out 
> of my local tree anyway.
> 
> The second problem is that when I build a file I do it like this:
> rake build/dir/file1.o.  The dep checking is never done because the .mf 
> file is specifies file.o not build/dir/file.o.  I am not sure what to do 
> about this one...
> 
> It looks like I may be better just to write my own dep checking tool...
> 
> Thought, tips?
> 
> ~S


I wrote a function which filters the output of gcc -MM to be compatible 
with rake.  It makes all paths relative, so rake does not choke on c:\, 
and also strips out api/SDK deps, so in the end it made my build faster 
anyway. :-)

~S

~S


From transfire at gmail.com  Wed Jan 31 10:25:07 2007
From: transfire at gmail.com (TRANS)
Date: Wed, 31 Jan 2007 10:25:07 -0500
Subject: [Rake-devel] Incresing GemPackageTask Efficiency
Message-ID: <4b6f054f0701310725l1827d0d0q9f002bd2a03b2dcf@mail.gmail.com>

Hi---

(I originally posted this to ruby-talk, but realized I should have
done so here.)

When using the GemPackageTask, one has to build the GemSpec in order
to define the task. For a large project and/or slow machine this
actually can take a second or so. So every time I run "rake -T" there's
a very noticeable delay (not to mention wasted CPU cycles). Not sure
what other solutions there might be, but one is to have GemPackageTask
accept the parameters that will build the GemSpec when needed, but not
before. So, instead of

     spec = Gem::Specification.new do |s|
       s.platform = Gem::Platform::RUBY
       s.summary = "Ruby based make-like utility."
       s.name = 'rake'
       s.files = FileList.new('**/*').to_a
       ...
     end

     Rake::GemPackageTask.new(spec) do |pkg|
       pkg.need_zip = true
       pkg.need_tar = true
     end

It could be:

     Rake::GemPackageTask.new do |pkg|
       pkg.platform = 'ruby'
       pkg.summary = "Ruby based make-like utility."
       pkg.name = 'rake'
       pkg.files.include '**/*'
       pkg.need_zip = true
       pkg.need_tar = true
     end

Note the difference in 'platform' and more importantly 'files'. The
GemPackageTask would work those out and build the GemSpec at runtime
rather then definition time.

Thanks,
T.

From murphy at rubychan.de  Wed Jan 31 15:17:37 2007
From: murphy at rubychan.de (murphy)
Date: Wed, 31 Jan 2007 21:17:37 +0100
Subject: [Rake-devel] Observer mode: new option --observe
Message-ID: <45C0F961.4050009@rubychan.de>

hi list!

I've implemented a new feature to Rake that seems very useful to me.

You can use the --observe (-O) option and an optional interval to start
Rake in an endless loop, like this:

% rake -O compile

and it will check every second if something has changed (until you kill it.)

I use this to compile .textile files to .html for example, so I don't
need to switch from my editor to the terminal every time. Helps a lot.

Another variant is to "daemonize" it:

% rake --silent --observe task &
% rake -sO task &
(not -Os!)

I attached both a patch and the new rake.rb file. As you can see, I had
to tweak Task#invoke to allow them to be called repeatedly.

Hope it works for you :)
[murphy]

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rake_observe.tar.gz
Type: application/x-gzip
Size: 18129 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/rake-devel/attachments/20070131/1e4b615a/attachment-0001.gz