From langstefan at gmx.at  Sat Feb  4 05:30:59 2006
From: langstefan at gmx.at (Stefan Lang)
Date: Sat, 4 Feb 2006 11:30:59 +0100
Subject: [Rant] 2 patches
In-Reply-To: <200601101544.45935.nickel@cip.ifi.lmu.de>
References: <200601101544.45935.nickel@cip.ifi.lmu.de>
Message-ID: <200602041131.00203.langstefan@gmx.at>


First let me say that I'm sorry that I haven't been able
to respond earlier.

On Tuesday 10 January 2006 15:44, Max Nickel wrote:
> Hi,
> i'd like to offer 2 patches for rant which i find useful.

Thank you!

> The first one changes Rant::RantApp#plugin to also accept
> Plugins not lying in rant/plugins. This way you can distribute
> custom plugins in the Rantfile or anywhere else without needing
> access to this directory. Right now you would have to put
>   'Rant::CODE_IMPORTS << "your_plugin"'
> in the Rantfile to get it loaded and i think this is unnecessary.

I see your point. But I recommend you to *not* use Rant's
current plugin interface. It will vanish as soon as there are
replacements for the two existing plugins ("Csharp" and
"Configure") distributed with Rant. I have added a warning
now to lib/rant/plugin/README.

You can achieve the same by using other hooks provided by Rant.
Look at RantContext#import (which delegates to Rant::RantApp#import),
Rant::RantApp#at_return, Rant::RantApp#at_resolve and other
methods in rant/rantlib.rb.

> The second one changes RubyTest to require 'test/unit' instead
> of running testrb as this is sufficient for TestCases and 'testrb'
> isnt available on all systems (debian-like use testrb1.8 for
> example)

testrb is really problematic. I will add an option to RubyTest
to allow usage of testrb, but the behaviour provided by your
patch will be the default.

> kind regards and keep up the great work
> /max

Kind regards,
  Stefan

From langstefan at gmx.at  Sat Feb  4 06:21:55 2006
From: langstefan at gmx.at (Stefan Lang)
Date: Sat, 4 Feb 2006 12:21:55 +0100
Subject: [Rant] sys.rant and -jN
In-Reply-To: <43DEE432.8090605@systemware.com>
References: <43DEE432.8090605@systemware.com>
Message-ID: <200602041221.55740.langstefan@gmx.at>

On Tuesday 31 January 2006 05:14, Kevin Burge wrote:
> Hi Stefan,
>
> I'm workng on an autobuild process, and I want to run rant for each
> "component".  Each component has it's own "root.rant" file.  How
> would you recommend calling this?  I thought about a sys.rant
> method, since you already have sys.ruby.  My ultimate goal is to
> have the "children" rant's not cause the overall build process to
> fail, but only the one that failed, and any of it's dependants. 
> I.e. if C depends on A and B, and if B fails to build, C shouldn't
> build, but D, E and F that are unrelated should still build (all of
> these components each having their own "root.rant").

Shouldn't be too hard to implement. The first decision is whether
you want to run each RantApp in a separate process or all in the
same.

Note that if you use Ruby constants and global variables and run
all Rant instances in the same process the constants and globals
will be shared, of course.

An example implementation:

###################################################################
module Rant::Sys
    def my_rant(*args, &block)
        success = nil
        cmd = lambda { ["rant", *args].join(' ') }
        if args.first == :p
            # run rant in new process
            args.shift
            sh("rant", *args) { |ps| success = ps.exitstatus == 0}
        else
            # run rant in this process/ruby interpreter
            fu_output_message(cmd.call)
            success = Rant::RantApp.new.run(*args) == 0
        end
        if block
            block.call(success)
        elsif !success
            raise Rant::CommandError.new(cmd.call, $?)
        end
    end
end
###################################################################

Now the sys.my_rant method runs an rant instance with the given
arguments like issuing the "rant arg1 arg2" from the commandline
would. If the first argument is the symbol :p, the instance
runs in a new process/ruby interpreter.
If the rant instance fails and no block was given to sys.my_rant,
it causes the calling rant instance to also fail.
If a block was given, error handling is delegated to the block
(which can of course ignore the error).

Example top level Rantfile:

  task :default => [:componentA, :componentB]

  task :componentA do
      # Run a new Rant instance in the directory A
      # and build foobar there. foobar is probably
      # defined in "A/root.rant"

      sys.my_rant "-C", "A", "foobar" { |success| }

      # The given block is for error handling. "success"
      # is a boolean.
      # In this case we ignore errors.
  end

  task :componentB do
      # Build "foobar" in directory "B". Run the new Rant
      # instance in a new process.
      sys.my_rant :p, "-C", "B", "foobar" { |success| }
  end

Now, if the default task is run, it will try to build all
components, and it will continue even if the build of
a component fails.

> Along these same lines: would it be difficult to add parallel
> dependency processing like the -jN switch to make? [...]

Yes that is difficult. I'm currently rewriting Rant's core
and if this attempt succeeds, Rant will be able to do
parallel processing of some tasks.

Regards,
  Stefan

P.S.: If you want I can explain why parallel processing is
      very hard to get right for Rant.

From newhoggy at gmail.com  Mon Feb 13 23:23:48 2006
From: newhoggy at gmail.com (John Ky)
Date: Tue, 14 Feb 2006 15:23:48 +1100
Subject: [Rant] Getting the root.rant directory
Message-ID: <bd4fcb030602132023j50d9822epd01863589ff97dcb@mail.gmail.com>

Hello,

If I want to have a source tree look like this:

/wrk/src/root.rant
/wrk/src/a/sub.rant
/wrk/src/a/b/sub.rant

And I'd like the output files to go into the directories like this:

/wrk/src/root.rant -> /wrk/build
/wrk/src/a/sub.rant -> /wrk/build/a
/wrk/src/a/b/sub.rant -> /wrk/build/a/b

What is the best way to go about this?

Thanks

-John


From ccr at mupad.de  Tue Feb 14 06:59:52 2006
From: ccr at mupad.de (Christopher Creutzig)
Date: Tue, 14 Feb 2006 12:59:52 +0100
Subject: [Rant] Large project structure?  Distributed builds?
Message-ID: <43F1C638.3070802@mupad.de>

[mail re-sent from correct account, apologies if multiple copies appear;
I did cancel the other mail in the webinterface.]


Salvete,

 I am currently evaluating make alternatives and did not find answers to
the following points in the rant documentation (which may be because I
looked in the wrong places):

 We have a large tree of sources of various kind in our cvs.  This
includes separate projects, libraries used by multiple projects etc.
What we are looking for in a make utility is the ability to only check
out what is needed for a single project (ideally, the tool would be able
to also pull other required parts from cvs, but that looks doable) and
invoke building it, yet also provide a single point of entry to build
?everything?, using global dependency analysis.  Can rant do that?

 Is rant ready for parallel builds?  If not, what is missing?  If yes,
how much work would it be to set up distributed builds, using a shared
file system and ssh or whatever method is easiest to do?  (distcc won't
cut it, since we are not dealing with C sources exclusively.)


Best regards,
	Christopher