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