From aslak.hellesoy at gmail.com Thu Sep 1 20:57:57 2005
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Thu Sep 1 20:51:08 2005
Subject: [Rake-devel] MetaProject
Message-ID: <8d961d90050901175774a4c4fd@mail.gmail.com>
Hi all,
(I also sent this to the RubyGems list)
The past month I've been working on a project (MetaProject:
http://xforge.rubyforge.org/) that among other things includes a quick
release system (QRS) for (among other places) RubyForge.
With MetaProject's Rake task, releasing new gems on RubyForge is a breeze:
task :release_files => [:gem] do
release_files = FileList[
"pkg/#{PKG_FILE_NAME}.gem"
]
Rake::XForge::Release.new(MetaProject::Project::XForge::RubyForge.new('xforge'))
do |release|
# Never hardcode user name and password in the Rakefile!
release.user_name = ENV['RUBYFORGE_USER']
release.password = ENV['RUBYFORGE_PASSWORD']
release.files = release_files.to_a
release.release_name = "MetaProject #{PKG_VERSION}"
# The rest of the options are defaults (among others,
release_notes and release_changes, parsed from CHANGES)
end
end
Would you consider mentioning this in the Rake documentation?
Cheers,
Aslak
From mutoh at highway.ne.jp Sun Sep 4 02:27:38 2005
From: mutoh at highway.ne.jp (Masao Mutoh)
Date: Sun Sep 4 02:20:48 2005
Subject: [Rake-devel] gempackagetask.rb small patch
Message-ID: <20050904152738.56842e48.mutoh@highway.ne.jp>
Hi,
I noticed Rake::GemPackageTask failes when
Gem::Platform was set to the value such as
Gem::Platform::CURRENT, WIN32.
Here is the smallest Rakefile to reproduce this problem.
----
require 'rubygems'
require 'rake'
require 'rake/packagetask'
require 'rake/gempackagetask'
spec = Gem::Specification.new do |s|
s.name = 'sample'
s.version = "1.0.0"
s.summary = 'sample'
s.platform = Gem::Platform::CURRENT
end
Rake::GemPackageTask.new(spec) do |p|
p.gem_spec = spec
p.need_tar_gz = false
p.need_zip = false
end
----
The result ws:
----
rake package
(in /home/mutoh/sample)
Successfully built RubyGem
Name: sample
Version: 1.0.0
File: sample-1.0.0-i686-linux.gem
mv sample-1.0.0.gem pkg/sample-1.0.0.gem
rake aborted!
No such file or directory - sample-1.0.0.gem
----
Attached patch fixes this problem.
HTH.
--
.:% Masao Mutoh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rake.patch
Type: application/octet-stream
Size: 430 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/rake-devel/attachments/20050904/8bf33e3e/rake.obj
From philipp.neubeck at gmx.de Sun Sep 4 05:19:50 2005
From: philipp.neubeck at gmx.de (philipp.neubeck@gmx.de)
Date: Sun Sep 4 05:13:00 2005
Subject: [Rake-devel] FileTask#needed? and FileTask#timestamp "bug"
Message-ID: <20050904111950.772d0832@alpha.lan>
Hi there,
think of the following situation:
file "foo"
file "bar" => [ "foo" ]
file "foo" does NOT exist, while "bar" does, then the timestamp method of bar's FileTask raises an unhandeled (not handeled by Rake) exception ('file not found...'), because it is called by "foo"'s FileTask#needed?.
i think there shouldn't be any exception thrown in this situation, but "bar" rebuild. if "bar" did not exist then "bar" would also be rebuild, so why not in this case. so my patch would be:
class FileTask
def needed?
return true unless File.exist?(name)
@prerequisites.each{|n| return true if Task[n].timestamp >= timestamp }
return false
rescue Errno::ENOENT => ex # one of the prereqs does not exist
raise unless $dryrun or $trace
true
end
def timestamp
return Time.now unless File.exist?( name )
File.mtime(name.to_s)
end
end
i also removed the collect{}.max. if one want's to check if the prerequisites exist, then do that but don't calculate a maximum, which is unneeded.
if it is supposed that 'needed?' is mainly called by Task#invoke then the checking should be there (see Task#invoke, it iterates the @prerequ..s already) and not here
hope it helps,
bye
phil
From patrick.bennett at inin.com Mon Sep 5 01:00:40 2005
From: patrick.bennett at inin.com (Patrick Bennett)
Date: Mon Sep 5 00:53:49 2005
Subject: [Rake-devel] FileTask#needed? and FileTask#timestamp "bug"
In-Reply-To: <20050904111950.772d0832@alpha.lan>
References: <20050904111950.772d0832@alpha.lan>
Message-ID: <431BD0F8.4030607@inin.com>
I simply patched my local rake's timestamp method to return Time.at(0)
for files that didn't exist as it fit the existing model better as far
as I was concerned.
Since I created a dependency generator for C++ source, it was possible
to generate dependencies for files (based on #include's) that might not
exist on a particular platform, so prerequisites that didn't exist had
to effectively be ignored.
Once you change the timestamp method to check for the existance of its
file and return a timestamp as appropriate, a rescue class in needed? is
no longer necessary.
However, IMO, in your example 'bar' should *not* be invoked. A missing
prerequisite should not be counted as a newer prerequisite.
Should a rule that specifies main.obj with a prereq of main.cpp cause an
attempted invokation of the main.obj rule when main.cpp is missing?
That's what you're stating here.
Patrick Bennett
philipp.neubeck@gmx.de wrote:
>Hi there,
>
>think of the following situation:
>
>file "foo"
>file "bar" => [ "foo" ]
>
>file "foo" does NOT exist, while "bar" does, then the timestamp method of bar's FileTask raises an unhandeled (not handeled by Rake) exception ('file not found...'), because it is called by "foo"'s FileTask#needed?.
>
>i think there shouldn't be any exception thrown in this situation, but "bar" rebuild. if "bar" did not exist then "bar" would also be rebuild, so why not in this case. so my patch would be:
>
>
>
>class FileTask
> def needed?
> return true unless File.exist?(name)
> @prerequisites.each{|n| return true if Task[n].timestamp >= timestamp }
> return false
> rescue Errno::ENOENT => ex # one of the prereqs does not exist
> raise unless $dryrun or $trace
> true
> end
>
> def timestamp
> return Time.now unless File.exist?( name )
> File.mtime(name.to_s)
> end
>end
>
>
>
>i also removed the collect{}.max. if one want's to check if the prerequisites exist, then do that but don't calculate a maximum, which is unneeded.
>if it is supposed that 'needed?' is mainly called by Task#invoke then the checking should be there (see Task#invoke, it iterates the @prerequ..s already) and not here
>
>
>hope it helps,
>
>bye
> phil
>_______________________________________________
>Rake-devel mailing list
>Rake-devel@rubyforge.org
>http://rubyforge.org/mailman/listinfo/rake-devel
>
>
From philipp.neubeck at gmx.de Mon Sep 5 06:37:51 2005
From: philipp.neubeck at gmx.de (philipp.neubeck@gmx.de)
Date: Mon Sep 5 06:31:45 2005
Subject: [Rake-devel] FileTask#needed? and FileTask#timestamp "bug"
In-Reply-To: <431BD0F8.4030607@inin.com>
References: <20050904111950.772d0832@alpha.lan>
<431BD0F8.4030607@inin.com>
Message-ID: <20050905123751.5675561f@alpha.lan>
On Mon, 05 Sep 2005 00:00:40 -0500
Patrick Bennett wrote:
> I simply patched my local rake's timestamp method to return Time.at(0)
> for files that didn't exist as it fit the existing model better as far
> as I was concerned.
> Since I created a dependency generator for C++ source, it was possible
> to generate dependencies for files (based on #include's) that might not
> exist on a particular platform, so prerequisites that didn't exist had
> to effectively be ignored.
> Once you change the timestamp method to check for the existance of its
> file and return a timestamp as appropriate, a rescue class in needed? is
> no longer necessary.
(in the current implementation: ) but if no timestamp as appropiate is returned but a exception thrown instead then the rescue in needed? does NOT catch the exception. it only catches missing tasks.
>
> However, IMO, in your example 'bar' should *not* be invoked. A missing
> prerequisite should not be counted as a newer prerequisite.
> Should a rule that specifies main.obj with a prereq of main.cpp cause an
> attempted invokation of the main.obj rule when main.cpp is missing?
> That's what you're stating here.
so if you do the opposite ( main.cpp is missing => no creation of main.obj ) the problem is that main.obj is simply in a _wrong_ state. the programmer should be able to recognize that there is something missing/wrong and so it should be tried to rebuild the main.obj or (if you say the prerequisites are a must) Rake should through an error.
ok i think the second would be better: no invokation of main.obj but Rake throwing an error. missing prerequisites should be counted as missing.
so let me repeat the example with main.cpp and main.obj as i think it should be:
file main.cpp
file main.obj => main.cpp
(let out timestamp) main.obj get's invoked (not yet excecuted), so rake first tries to create the prerequisites. the file task main.cpp sees that the file is missing and says it is "needed" (see the FileTask#needed? code). file main.cpp gets invoked and excecuted but since there's no attached action rake throughs an error, that it can't create a needed file.
the timestamp stuff should reflect this, so timestamp of a missing file must return "now" as it is always needed to be invoked.
i see the point you state with the platform dependend prerequisites. and therefore you would need something like optional dependencies. but i don't see a way how to distinguish optional and needed prerequisites on c++ site, because (i think you did that too) the dependencies are autogenerated by gcc.
hmm... or does gcc -MM -MG utilize the precompiler and then read the dependencies? (#include keyword is for the precompiler too) then you should be able to solve this problem with common #defines for your platforms (i think you did this anyway, or you would get compile errors, because of missing includes)
anyway, i think all we said is better than the current implementation. because the current throws exceptions and you don't know where they come from.
bye
phil
(i hope i don't write too crappish, cause im normally talking german)
From jim at weirichhouse.org Mon Sep 5 15:47:33 2005
From: jim at weirichhouse.org (Jim Weirich)
Date: Mon Sep 5 15:39:45 2005
Subject: [Rake-devel] MetaProject
In-Reply-To: <8d961d90050901175774a4c4fd@mail.gmail.com>
References: <8d961d90050901175774a4c4fd@mail.gmail.com>
Message-ID: <200509051547.34019.jim@weirichhouse.org>
On Thursday 01 September 2005 08:57 pm, aslak hellesoy wrote:
> Hi all,
>
> (I also sent this to the RubyGems list)
>
> The past month I've been working on a project (MetaProject:
> http://xforge.rubyforge.org/) that among other things includes a quick
> release system (QRS) for (among other places) RubyForge.
>
> With MetaProject's Rake task, releasing new gems on RubyForge is a breeze:
Aslak,
I'm really excited about this project. This will be a great help.
Unfortunately, I has a few problems ...
(1) The CHANGES file couldn't be parsed, resulting in an error message and a
stack dump ... but the rake file continued processing. The message should
clearly be labled a warning and the stack dump avoided unless the --trace
option is given. Even better would be a way of disabling CHANGES parsing.
(I'm not sure why it was failing ... my format looks similar to yours,
perhaps my version numbers weren't matching).
(2) I wanted to enter the username/password interactively. Unfortunately an
undefined @host instance variable caused problems. I worked around it with:
Host = Struct.new(:name)
release.instance_eval { @host = Host.new('RubyForge') }
(3) I got a "couldn't find package_id" message. I enabled --trace on the rake
command and got the following output. I didn't follow it any farther ...
About to release 'REL_0.5.4.7'
Files:
rake-0.5.4.7.gem
rake-0.5.4.7.tgz
rake-0.5.4.7.zip
Release Notes:
nil
Release Changes:
nil
Release Settings:
Preformatted: true
Processor: 8000
Starting release...
Releasing rake-0.5.4.7.gem...
rake aborted!
Couldn't get package_id
/usr/local/lib/ruby/gems/1.8/gems/meta_project-0.4.6/lib/meta_project/project/xforge/session.rb:41:in
`package_id'
/usr/local/lib/ruby/gems/1.8/gems/meta_project-0.4.6/lib/meta_project/project/xforge/session.rb:75:in
`release'
/usr/local/lib/ruby/gems/1.8/gems/meta_project-0.4.6/lib/meta_project/project/xforge/session.rb:71:in
`start'
/usr/local/lib/ruby/1.8/net/http.rb:323:in `start'
/usr/local/lib/ruby/gems/1.8/gems/meta_project-0.4.6/lib/meta_project/project/xforge/session.rb:71:in
`release'
/usr/local/lib/ruby/gems/1.8/gems/meta_project-0.4.6/lib/meta_project/project/xforge/session.rb:67:in
`each_with_index'
/usr/local/lib/ruby/gems/1.8/gems/meta_project-0.4.6/lib/meta_project/project/xforge/session.rb:67:in
`each'
/usr/local/lib/ruby/gems/1.8/gems/meta_project-0.4.6/lib/meta_project/project/xforge/session.rb:67:in
`each_with_index'
/usr/local/lib/ruby/gems/1.8/gems/meta_project-0.4.6/lib/meta_project/project/xforge/session.rb:67:in
`release'
/usr/local/lib/ruby/gems/1.8/gems/meta_project-0.4.6/lib/rake/contrib/xforge/release.rb:73:in
`execute'
/usr/local/lib/ruby/gems/1.8/gems/meta_project-0.4.6/lib/rake/contrib/xforge/base.rb:15:in
`initialize'
./Rakefile:383:in `new'
./Rakefile:383
./Rakefile:374:in `call'
./lib/rake.rb:200:in `execute'
./lib/rake.rb:200:in `each'
./lib/rake.rb:200:in `execute'
./lib/rake.rb:178:in `invoke'
./lib/rake.rb:1431:in `run'
./lib/rake.rb:1431:in `each'
./lib/rake.rb:1431:in `run'
bin/rake:7
--
-- Jim Weirich jim@weirichhouse.org http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
From jim at weirichhouse.org Mon Sep 5 16:23:03 2005
From: jim at weirichhouse.org (Jim Weirich)
Date: Mon Sep 5 16:15:13 2005
Subject: [Rake-devel] MetaProject
In-Reply-To: <200509051547.34019.jim@weirichhouse.org>
References: <8d961d90050901175774a4c4fd@mail.gmail.com>
<200509051547.34019.jim@weirichhouse.org>
Message-ID: <200509051623.03747.jim@weirichhouse.org>
On Monday 05 September 2005 03:47 pm, Jim Weirich wrote:
> (1) The CHANGES file couldn't be parsed, [...]
> (I'm not sure why it was failing ... my format looks similar to
> yours, perhaps my version numbers weren't matching).
Just to confirm, the version in the package was different than the version in
the CHANGES file. It wasn't finding the set of changes.
--
-- Jim Weirich jim@weirichhouse.org http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
From jim at weirichhouse.org Mon Sep 5 20:45:35 2005
From: jim at weirichhouse.org (Jim Weirich)
Date: Mon Sep 5 20:37:46 2005
Subject: [Rake-devel] Rake 0.6.0 Released
Message-ID: <200509052045.35411.jim@weirichhouse.org>
= Rake 0.6.0 Released
Its time for some long requested enhancements and lots of bug fixes
... And a whole new web page.
== New Web Page
The primary documentation for rake has moved from the RubyForge based
wiki to its own Hieraki based web site. Constant spam on the wiki
made it a difficult to keep clean. The new site will be easier to
update and organize.
Check out the new documentation at: http://docs.rubyrake.org
We will be adding new documentation to the site as time goes on.
In addition to the new docs page, make sure you check out Martin
Fowlers article on rake at http://martinfowler.com/articles/rake.html
== Changes
=== New Features
* Multiple prerequisites on Rake rules now allowed. However, keep the
following in mind:
1. All the prerequisites of a rule must be available before a rule
is triggered, where "enabled" means (a) an existing file, (b) a
defined rule, or (c) another rule which also must be
trigger-able.
2. Rules are checked in order of definition, so it is important to
order your rules properly. If a file can be created by two
different rules, put the more specific rule first (otherwise the
more general rule will trigger first and the specific one will
never be triggered).
3. The source method now returns the name of the first
prerequisite listed in the rule. sources returns the
names of all the rule prerequisites, ordered as they are defined
in the rule. If the task has other prerequisites not defined in
the rule (but defined in an explicit task definition), then they
will _not_ be included in the sources list.
* FileLists may now use the egrep command. This popular enhancement
is now a core part of the FileList object. If you want to get a
list of all your to-dos, fixmes and TBD comments, add the following
to your Rakefile.
desc "Look for TODO and FIXME tags in the code"
task :todo do
FileList['**/*.rb'].egrep /#.*(FIXME|TODO|TBD)/
end
* The investigation method was added to task object to dump
out some important values. This makes it a bit easier to debug Rake
tasks.
For example, if you are having problems with a particular task, just
print it out:
task :huh do
puts Rake::Task['huh'].investigation
end
* The Rake::TestTask class now supports a "ruby_opts" option to pass
arbitrary ruby options to a test subprocess.
=== Some Incompatibilities
* When using the ruby command to start a Ruby subprocess, the
Ruby interpreter that is currently running rake is used by default.
This makes it easier to use rake in an environment with multiple
ruby installation. (Previously, the first ruby command found in the
PATH was used).
If you wish to chose a different Ruby interpreter, you can
explicitly choose the interpreter via the sh command.
* The major rake classes (Task, FileTask, FileCreationTask, RakeApp)
have been moved out of the toplevel scope and are now accessible as
Rake::Task, Rake::FileTask, Rake::FileCreationTask and
Rake::Application. If your Rakefile
directly references any one of these tasks, you may:
1. Update your Rakefile to use the new classnames
2. Use the --classic-namespace option on the rake command to get the
old behavior,
3. Add require 'rake/classic_namespace' to the
Rakefile to get the old behavior.
rake will print a rather annoying warning whenever a
deprecated class name is referenced without enabling classic
namespace.
=== Bug Fixes
* Several unit tests and functional tests were fixed to run better
under windows.
* Directory tasks are now a specialized version of a File task. A
directory task will only be triggered if it doesn't exist. It will
not be triggered if it is out of date w.r.t. any of its
prerequisites.
* Fixed a bug in the Rake::GemPackageTask class so that the gem now
properly contains the platform name.
* Fixed a bug where a prerequisite on a file task would cause
an exception if the prerequisite did not exist.
== What is Rake
Rake is a build tool similar to the make program in many ways. But
instead of cryptic make recipes, Rake uses standard Ruby code to
declare tasks and dependencies. You have the full power of a modern
scripting language built right into your build tool.
== Availability
The easiest way to get and install rake is via RubyGems ...
gem install rake (you may need root/admin privileges)
Otherwise, you can get it from the more traditional places:
Home Page:: http://rake.rubyforge.org/
Download:: http://rubyforge.org/project/showfiles.php?group_id=50
== Thanks
As usual, it was input from users that drove a alot of these changes.
The following people either contributed patches, made suggestions or
made otherwise helpful comments. Thanks to ...
* Greg Fast (better ruby_opt test options)
* Kelly Felkins (requested by better namespace support)
* Martin Fowler (suggested Task.investigation)
* Stuart Jansen (send initial patch for multiple prerequisites).
* Masao Mutch (better support for non-ruby Gem platforms)
* Philipp Neubeck (patch for file task exception fix)
--
-- Jim Weirich jim@weirichhouse.org http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
From patrick.bennett at inin.com Mon Sep 5 22:05:16 2005
From: patrick.bennett at inin.com (Patrick Bennett)
Date: Mon Sep 5 21:58:23 2005
Subject: [Rake-devel] FileTask#needed? and FileTask#timestamp "bug"
In-Reply-To: <20050905123751.5675561f@alpha.lan>
References: <20050904111950.772d0832@alpha.lan> <431BD0F8.4030607@inin.com>
<20050905123751.5675561f@alpha.lan>
Message-ID: <431CF95C.2060202@inin.com>
philipp.neubeck@gmx.de wrote:
>so if you do the opposite ( main.cpp is missing => no creation of main.obj ) the problem is that main.obj is simply in a _wrong_ state. the programmer should be able to recognize that there is something missing/wrong and so it should be tried to rebuild the main.obj or (if you say the prerequisites are a must) Rake should through an error.
>ok i think the second would be better: no invokation of main.obj but Rake throwing an error. missing prerequisites should be counted as missing.
>
>so let me repeat the example with main.cpp and main.obj as i think it should be:
>
>file main.cpp
>file main.obj => main.cpp
>
>(let out timestamp) main.obj get's invoked (not yet excecuted), so rake first tries to create the prerequisites. the file task main.cpp sees that the file is missing and says it is "needed" (see the FileTask#needed? code). file main.cpp gets invoked and excecuted but since there's no attached action rake throughs an error, that it can't create a needed file.
>
>the timestamp stuff should reflect this, so timestamp of a missing file must return "now" as it is always needed to be invoked.
>
>
This isn't the behavior you would want with auto-generated dependencies
of header files. I guess it wouldn't really matter in my case since the
prerequisite tasks my dependency generation code creates are special
'Header' tasks which have different timestamp and needed? behaviors.
It's quite possible I changed the base FileTask code originally because
I hadn't defined CSourceFileTask (which know when to generate
dependencies) and HeaderFileTask classes yet. In case you're
interested, I also ended up modifying all base 'timestamp' methods to
take a parent task name parameter so that a task like CSourceFileTask
could check if it was newer than its parent and bypass having to
generate dependencies if so (why scan all headers for main.cpp if
main.cpp got changed and is newer than main.o ?).
>i see the point you state with the platform dependend prerequisites. and therefore you would need something like optional dependencies. but i don't see a way how to distinguish optional and needed prerequisites on c++ site, because (i think you did that too) the dependencies are autogenerated by gcc.
>
>
Well, actually, my code generates the dependencies and does it far
faster than any other dependency system I've used. Since my dependency
scanner doesn't try to be a full preprocessor (there's hardly any reason
honestly) and simply greps for #include lines, it pulls in *all*
possible include's. Of course, my scanner has to replicate the search
order and file resolution rules of the preprocessor, but that was easy.
So the net effect is, worst case, if say a header for a windows-only
compiles changed, it would still cause the source files dependent on
that header to recompile under linux. Of course, unless you're doing
full cross-compilation from the same build area, this really isn't an
issue. We happen to be doing so, but I'd much prefer the occasional
over-zealous recompile of a module then having things skipped that
should've been recompiled. Of course, the fact that all #include's are
defined as as prerequisites makes it imperative for a missing file to
not be treated as 'now' as it would *always* cause recompilation.
>hmm... or does gcc -MM -MG utilize the precompiler and then read the dependencies? (#include keyword is for the precompiler too) then you should be able to solve this problem with common #defines for your platforms (i think you did this anyway, or you would get compile errors, because of missing includes)
>
>
Using the full preprocessor is hopelessly slow for generating
dependencies (particularly if it has to output to a file before the
output can be scanned). A preprocessor step would create 10+MB files
for almost any source file in one of our projects and take quite a while
per file. With the simple regex grep method, it's no more than a second
or so per file (and previously fetched header dependency trees are
cached) so it gets faster once its scanned a source file or two.
>anyway, i think all we said is better than the current implementation. because the current throws exceptions and you don't know where they come from.
>
>
Agreed.
*Patrick Bennett* | Software Engineer
phone & fax +1.317.715.8302 | patrick.bennett@inin.com
*Interactive Intelligence Inc.*
Deliberately Innovative
www.inin.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rake-devel/attachments/20050905/4197d281/attachment-0001.htm
From djberg96 at yahoo.com Mon Sep 5 22:12:41 2005
From: djberg96 at yahoo.com (Daniel Berger)
Date: Mon Sep 5 22:05:45 2005
Subject: [Rake-devel] Rake 0.6.0 Released
In-Reply-To: <200509052045.35411.jim@weirichhouse.org>
Message-ID: <20050906021242.73296.qmail@web50312.mail.yahoo.com>
--- Jim Weirich wrote:
> = Rake 0.6.0 Released
Hi Jim,
Glad to hear 0.6.0 is out! A couple of
suggestions/questions.
* In the README file include instructions for how to
run the test suite (for those of us installing from
scratch instead of gems). If there are already
instructions somewhere, I didn't see them.
* Wasn't there a "test_all.rb" file, or something
similar, that would run all the tests? What happened
to it?
* The $LOAD_PATH of the tests should be modified to
ensure that they're testing against the current
release, not an already-installed released. See
http://www.livejournal.com/users/djberg96/41703.html
for what I mean.
Regards,
Dan
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
From jim at weirichhouse.org Mon Sep 5 23:54:51 2005
From: jim at weirichhouse.org (Jim Weirich)
Date: Mon Sep 5 23:47:03 2005
Subject: [Rake-devel] Rake 0.6.0 Released
In-Reply-To: <20050906021242.73296.qmail@web50312.mail.yahoo.com>
References: <20050906021242.73296.qmail@web50312.mail.yahoo.com>
Message-ID: <200509052354.51269.jim@weirichhouse.org>
On Monday 05 September 2005 10:12 pm, Daniel Berger wrote:
> --- Jim Weirich wrote:
> > = Rake 0.6.0 Released
>
> Hi Jim,
>
> Glad to hear 0.6.0 is out! A couple of
> suggestions/questions.
>
> * In the README file include instructions for how to
> run the test suite (for those of us installing from
> scratch instead of gems). If there are already
> instructions somewhere, I didn't see them.
If you already have a version of rake installed:
rake
If you don't have a version of rake installed:
ruby -Ilib bin/rake
You're right, it should be documented.
> * Wasn't there a "test_all.rb" file, or something
> similar, that would run all the tests? What happened
> to it?
Nope, never was. (at least not in recent memory)
> * The $LOAD_PATH of the tests should be modified to
> ensure that they're testing against the current
> release, not an already-installed released. See
> http://www.livejournal.com/users/djberg96/41703.html
> for what I mean.
That's unnecessary if testing using the built in Rake TestTask. Rake makes
sure you always run the tests from the project directory (where ever the
Rakefile is located) and the TestTask makes sure your local library paths are
used in preference to the global ones.
--
-- Jim Weirich jim@weirichhouse.org http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
From djberg96 at yahoo.com Tue Sep 6 00:08:43 2005
From: djberg96 at yahoo.com (Daniel Berger)
Date: Tue Sep 6 00:02:00 2005
Subject: [Rake-devel] Rake 0.6.0 Released
In-Reply-To: <200509052354.51269.jim@weirichhouse.org>
Message-ID: <20050906040843.67571.qmail@web50301.mail.yahoo.com>
--- Jim Weirich wrote:
> On Monday 05 September 2005 10:12 pm, Daniel Berger
> wrote:
> > --- Jim Weirich wrote:
> > > = Rake 0.6.0 Released
> >
> > Hi Jim,
> >
> > Glad to hear 0.6.0 is out! A couple of
> > suggestions/questions.
> >
> > * In the README file include instructions for how
> to
> > run the test suite (for those of us installing
> from
> > scratch instead of gems). If there are already
> > instructions somewhere, I didn't see them.
>
> If you already have a version of rake installed:
>
> rake
>
> If you don't have a version of rake installed:
>
> ruby -Ilib bin/rake
>
> You're right, it should be documented.
>
> > * Wasn't there a "test_all.rb" file, or something
> > similar, that would run all the tests? What
> happened
> > to it?
>
> Nope, never was. (at least not in recent memory)
>
> > * The $LOAD_PATH of the tests should be modified
> to
> > ensure that they're testing against the current
> > release, not an already-installed released. See
> >
> http://www.livejournal.com/users/djberg96/41703.html
> > for what I mean.
>
> That's unnecessary if testing using the built in
> Rake TestTask. Rake makes
> sure you always run the tests from the project
> directory (where ever the
> Rakefile is located) and the TestTask makes sure
> your local library paths are
> used in preference to the global ones.
Ah, ok. Thanks!
Dan
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
From jim at weirichhouse.org Tue Sep 6 00:41:38 2005
From: jim at weirichhouse.org (Jim Weirich)
Date: Tue Sep 6 00:33:47 2005
Subject: [Rake-devel] FileTask#needed? and FileTask#timestamp "bug"
In-Reply-To: <431CF95C.2060202@inin.com>
References: <20050904111950.772d0832@alpha.lan>
<20050905123751.5675561f@alpha.lan> <431CF95C.2060202@inin.com>
Message-ID: <200509060041.38287.jim@weirichhouse.org>
Regarding the behavior of timestamp when the file doesn't exist:
I went with the time stamp of a non-existing file should be a time stamp that
is earlier than any existing file. The biggest reason is that using a late
time stamp for non-existing files would cause the target to be continually
rebuilt, and that just doesn't make sense.
Anyways, the change is in the 0.6.0 just out today.
--
-- Jim Weirich jim@weirichhouse.org http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
From philipp.neubeck at gmx.de Tue Sep 6 05:27:30 2005
From: philipp.neubeck at gmx.de (philipp.neubeck@gmx.de)
Date: Tue Sep 6 05:20:37 2005
Subject: [Rake-devel] FileTask#needed? and FileTask#timestamp "bug"
In-Reply-To: <200509060041.38287.jim@weirichhouse.org>
References: <20050904111950.772d0832@alpha.lan>
<20050905123751.5675561f@alpha.lan> <431CF95C.2060202@inin.com>
<200509060041.38287.jim@weirichhouse.org>
Message-ID: <20050906112730.25b9e77c@alpha.lan>
On Tue, 6 Sep 2005 00:41:38 -0400
Jim Weirich wrote:
> Regarding the behavior of timestamp when the file doesn't exist:
>
> I went with the time stamp of a non-existing file should be a time stamp that
> is earlier than any existing file. The biggest reason is that using a late
> time stamp for non-existing files would cause the target to be continually
> rebuilt, and that just doesn't make sense.
>
> Anyways, the change is in the 0.6.0 just out today.
first, before any one gets angry because i don't just say 'you're right' :-), i rate this problem (if it's any) as minor.
sorry if i'm a a bit (or very) blind, but let me explain why i think you're both wrong:
the normal user of Rake, should tell Rake the truth about his dependencies, i.e. if you insert a dependency the target should only be correctly invokable if the prerequisite is fullfilled. (any other behaviour is special and can be changed by each user)
so the behaviour Patrick mentions is IMO not the general behaviour a Rake user (should :-) wants, because he inserts dependencies which aren't any (he does not tell the Rake system everything he knows!)
so in this "normal" case, what you say Jim (...the target would be continually rebuilt...) is not right:
the file thats missing would be relevant to rebuilt the target, but since it's non-existant, the target-rebuilt would fail, so the user would see it failed and has to correct the problem.
example:
main.exe needs main.cpp needs main.hpp. you correctly built with rake. then you rename main.hpp and reinvoke rake, but rake would just do nothing. or say you changed some pieces of your dependency generator wrongly and it produces filenames of non-existant files, then rake would not complain, never, not even a warning.
i hope the behaviour i described is understandable. the only question is what should be the standard, the one you describe or i describe.
i don't know if it would be better to make both behaviours accessable.
bye
Phil
From aslak.hellesoy at gmail.com Tue Sep 6 19:05:02 2005
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Tue Sep 6 18:58:04 2005
Subject: [Rake-devel] MetaProject
In-Reply-To: <200509051547.34019.jim@weirichhouse.org>
References: <8d961d90050901175774a4c4fd@mail.gmail.com>
<200509051547.34019.jim@weirichhouse.org>
Message-ID: <8d961d9005090616051e50a427@mail.gmail.com>
On 9/5/05, Jim Weirich wrote:
> On Thursday 01 September 2005 08:57 pm, aslak hellesoy wrote:
> > Hi all,
> >
> > (I also sent this to the RubyGems list)
> >
> > The past month I've been working on a project (MetaProject:
> > http://xforge.rubyforge.org/) that among other things includes a quick
> > release system (QRS) for (among other places) RubyForge.
> >
> > With MetaProject's Rake task, releasing new gems on RubyForge is a breeze:
>
> Aslak,
>
> I'm really excited about this project. This will be a great help.
>
> Unfortunately, I has a few problems ...
>
Ouch, I'm sorry about that. Read on.
> (1) The CHANGES file couldn't be parsed, resulting in an error message and a
> stack dump ... but the rake file continued processing. The message should
> clearly be labled a warning and the stack dump avoided unless the --trace
> option is given. Even better would be a way of disabling CHANGES parsing.
> (I'm not sure why it was failing ... my format looks similar to yours,
> perhaps my version numbers weren't matching).
>
It could be that the version numbers weren't matching.
MetaProject::VersionParser now raises a detailed exception and
interrupts Rake if it can't parse the CHANGES file.
I have also added a FAQ (http://xforge.rubyforge.org/) that describes
how to disable parsing of the CHANGES file (in which case you have to
supply the release notes and changes in the Rakefile).
> (2) I wanted to enter the username/password interactively. Unfortunately an
> undefined @host instance variable caused problems. I worked around it with:
>
> Host = Struct.new(:name)
> release.instance_eval { @host = Host.new('RubyForge') }
>
Glitch on my part that is fixed now. (I have my env vars set in
.bashrc and this part doesn't have unit tests, so I never encountered
it).
> (3) I got a "couldn't find package_id" message. I enabled --trace on the rake
> command and got the following output. I didn't follow it any farther ...
>
(snip)
Yep, that was a bug that should be fixed now.
I have released MetaProject 0.4.8 that hopefully fixes all of the
problems you encountered. (I have only tried it, not proved it
correct! I haven't spent much time unit testing the rake task under
different conditions). Please let me know if it works/doesn't work for
you this time.
Thanks for testing it out and giving good feedback!
Cheers,
Aslak
> -- Jim Weirich jim@weirichhouse.org http://onestepback.org
> -----------------------------------------------------------------
> "Beware of bugs in the above code; I have only proved it correct,
> not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
>
From neoneye at gmail.com Sun Sep 11 07:04:51 2005
From: neoneye at gmail.com (Simon Strandgaard)
Date: Sun Sep 11 06:57:46 2005
Subject: [Rake-devel] rake snippets
Message-ID:
Sometimes when eating I browse around the net, to see if I can find
something useful. Today I wanted to see if there were a collection
of useful rake tasks. I am not looking for anything particular,
but perhaps my rake task for doing the daily svn backup could be
simplified.. stuff like that.
So perhaps it would be a good thing to start such snippet collection?
Thanks for a wonderful tool :-)
--
Simon Strandgaard
# here is my 'svn backup snippet'..
#
task :default => :svnbackup
task :svnbackup do
repos = '/Users/simonstrandgaard/code/svnrepos'
revstr = `svnlook youngest #{repos}`
rev = '_rev' + revstr.match(/\d+/).to_s
#p rev
filename = 'backup' + Time.now.strftime('%Y%m%d')
filename += rev
filename += '.gz'
p filename
sh "svnadmin dump #{repos} | gzip -9 > #{filename}"
end
From ludvig.omholt at it.su.se Mon Sep 19 03:44:26 2005
From: ludvig.omholt at it.su.se (Ludvig Omholt)
Date: Mon, 19 Sep 2005 09:44:26 +0200
Subject: [Rake-devel] small fix for safe_ln
Message-ID: <20050919074426.GC12492@it.su.se>
Hi,
I am using rake with OpenAFS. AFS does not support hard links but the
errno differs from the one used with rescue in safe_ln. The error when
trying to do hard links in AFS is the same as when trying to do hard
links between different filesystems; invalid cross-device
link. Attached is a small, mostly harmless, patch against current CVS
that fixes the issue.
/ludde
--
Ludvig Omholt
Sektionen f?r IT och media
Stockholms universitet
-------------- next part --------------
Index: lib/rake.rb
===================================================================
RCS file: /var/cvs/rake/rake/lib/rake.rb,v
retrieving revision 1.112
diff -u -r1.112 rake.rb
--- lib/rake.rb 14 Sep 2005 04:51:29 -0000 1.112
+++ lib/rake.rb 14 Sep 2005 11:11:37 -0000
@@ -604,7 +604,7 @@
else
begin
ln(*args)
- rescue Errno::EOPNOTSUPP
+ rescue Errno::EOPNOTSUPP, Errno::EXDEV
LN_SUPPORTED[0] = false
cp(*args)
end
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://rubyforge.org/pipermail/rake-devel/attachments/20050919/1972b2ff/attachment.bin
From jim at weirichhouse.org Mon Sep 19 08:42:40 2005
From: jim at weirichhouse.org (Jim Weirich)
Date: Mon, 19 Sep 2005 08:42:40 -0400
Subject: [Rake-devel] small fix for safe_ln
In-Reply-To: <20050919074426.GC12492@it.su.se>
References: <20050919074426.GC12492@it.su.se>
Message-ID: <200509190842.41110.jim@weirichhouse.org>
On Monday 19 September 2005 03:44 am, Ludvig Omholt wrote:
> Hi,
>
> I am using rake with OpenAFS. AFS does not support hard links but the
> errno differs from the one used with rescue in safe_ln. The error when
> trying to do hard links in AFS is the same as when trying to do hard
> links between different filesystems; invalid cross-device
> link. Attached is a small, mostly harmless, patch against current CVS
> that fixes the issue.
Thanks ... commited to CVS.
--
-- Jim Weirich jim at weirichhouse.org http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
From dougkearns at gmail.com Wed Sep 21 01:29:22 2005
From: dougkearns at gmail.com (Doug Kearns)
Date: Wed, 21 Sep 2005 15:29:22 +1000
Subject: [Rake-devel] FileUtils#cd and :noop in 1.8.3
Message-ID: <20050921052922.GY8173@localhost.localdomain>
G'day Jim,
It seems that Rake is currently broken when running under 1.8.3 as
FileUtils#cd doesn't accept the :noop option anymore.
Regards,
Doug
From jim at weirichhouse.org Wed Sep 21 06:56:10 2005
From: jim at weirichhouse.org (Jim Weirich)
Date: Wed, 21 Sep 2005 06:56:10 -0400
Subject: [Rake-devel] FileUtils#cd and :noop in 1.8.3
In-Reply-To: <20050921052922.GY8173@localhost.localdomain>
References: <20050921052922.GY8173@localhost.localdomain>
Message-ID: <200509210656.10690.jim@weirichhouse.org>
On Wednesday 21 September 2005 01:29 am, Doug Kearns wrote:
> G'day Jim,
>
> It seems that Rake is currently broken when running under 1.8.3 as
> FileUtils#cd doesn't accept the :noop option anymore.
Rats. I haven't tried 1.8.3 yet. Thanks for the heads up.
Anything else broken?
--
-- Jim Weirich jim at weirichhouse.org http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
From dougkearns at gmail.com Wed Sep 21 07:39:57 2005
From: dougkearns at gmail.com (Doug Kearns)
Date: Wed, 21 Sep 2005 21:39:57 +1000
Subject: [Rake-devel] FileUtils#cd and :noop in 1.8.3
In-Reply-To: <200509210656.10690.jim@weirichhouse.org>
References: <20050921052922.GY8173@localhost.localdomain>
<200509210656.10690.jim@weirichhouse.org>
Message-ID: <20050921113957.GB8173@localhost.localdomain>
On Wed, Sep 21, 2005 at 06:56:10AM -0400, Jim Weirich wrote:
> On Wednesday 21 September 2005 01:29 am, Doug Kearns wrote:
> > G'day Jim,
> >
> > It seems that Rake is currently broken when running under 1.8.3 as
> > FileUtils#cd doesn't accept the :noop option anymore.
>
> Rats. I haven't tried 1.8.3 yet. Thanks for the heads up.
>
> Anything else broken?
Not that I've noticed. Once I fix the above issue all my rakefiles seem
to be running correctly...
Regards,
Doug