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 Sun, 10 May 2009 02:26:42 GMT
On Fri, May 8, 2009 at 5:57 PM, Daniel Spiewak <djspiewak@gmail.com> wrote:

> Unfortunately, this technique leads to circular dependencies.  This might
> be
> something that we want to work on in future, since I would imagine that
> this
> sort of thing is fairly common.


If gll-combinators depends on examples and examples depends
on gll-combinators, then yes, you'll get circular dependencies. But if you
have a known-to-work buildfile then it should be possible (with some effort)
to split it up, that in itself should not introduce circular dependencies.

Assaf


>
>
> Daniel
>
> On Fri, May 8, 2009 at 11:22 AM, Assaf Arkin <arkin@intalio.com> wrote:
>
> > 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