buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Assaf Arkin <ar...@intalio.com>
Subject Re: Correct Way to Depend on Another Buildfile
Date Fri, 08 May 2009 16:22:45 GMT
On Thu, May 7, 2009 at 8:18 AM, Daniel Spiewak <djspiewak@gmail.com> wrote:

> Consider: http://github.com/djspiewak/gll-combinators
>
> Specifically, the examples/ directory defines a separate Buildr project
> which depends upon the project in its parent directory (gll-combinators).
>  I
> could have done this by using two sub-projects, but I wanted a very
> specific
> directory organization.  In other words, I wanted the main sources to be
> under gll-combinators/src/main/scala/ while the examples are under
> examples/src/main/scala/.
>
> Currently, I'm handling this by actually shelling out to Buildr from within
> the examples/ buildfile, building the parent project and then explicitly
> adding its target/classes/ directory to the examples/ dependencies.  Is
> there a better way of doing this?  Better question: *shouldn't* there be a
> better way of doing this?  :-)


Yes.

Project definitions should be portable, so if you did everything by the
book, you should be able to import gll-combinators from within examples (or
the other way around). Some gotaches:

- You build now runs from a different directory, anything that assumes
relative paths is broken, but anything that uses _(..) will adjust. For
that, imported projects need to set their base_dir.
- Project references are relative, so if you have some 'master' project and
you import foo and bar, they can reference each other foo:module1,
bar:compA, etc.
- Globals may conflicts (and constants will warn you when they're redefined)
- Build settings (build.yml, profile.yml): you can only use one of these.

Generally easier (and from what I've heard more common) to start with the
outer buildfile and import nested buildfiles from its sub-directories. Would
be easier if everything we do only supports that, so let's use that as a
mental model for what you're doing.

>From examples/buildfile:

- cd one level up, since you're effectively running the build from here.
- require gll-combinators, everything you do afterwards should extend it
- define the examples projects, base_dir should just point one level down
(since you're current dir is now one level up)

(You won't get tasks/build.yml/etc from the outer directory since the
directory change happens to late, but if the model works, we could make
Buildr do the right thing with some magic switch)

Assaf


>
> Optimally, I would like to just `require` the parent's buildfile and then
> using project('gll-combinators') to declare the dependency within the
> examples/ buildfile.  However, Buildr doesn't seems to have some global
> state relating to project definitions, meaning that this sort of thing
> doesn't work at present.



>
>
> Daniel
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message