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.
Daniel On Fri, May 8, 2009 at 11:22 AM, Assaf Arkin <[email protected]> wrote: > On Thu, May 7, 2009 at 8:18 AM, Daniel Spiewak <[email protected]> > 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 > > >
