Return-Path: Delivered-To: apmail-incubator-buildr-user-archive@locus.apache.org Received: (qmail 88093 invoked from network); 30 Jun 2008 11:14:42 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 30 Jun 2008 11:14:42 -0000 Received: (qmail 8808 invoked by uid 500); 30 Jun 2008 11:14:43 -0000 Delivered-To: apmail-incubator-buildr-user-archive@incubator.apache.org Received: (qmail 8717 invoked by uid 500); 30 Jun 2008 11:14:43 -0000 Mailing-List: contact buildr-user-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: buildr-user@incubator.apache.org Delivered-To: mailing list buildr-user@incubator.apache.org Received: (qmail 8706 invoked by uid 99); 30 Jun 2008 11:14:43 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 30 Jun 2008 04:14:43 -0700 X-ASF-Spam-Status: No, hits=2.6 required=10.0 tests=DNS_FROM_OPENWHOIS,SPF_HELO_PASS,SPF_PASS,WHOIS_MYPRIVREG X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of lists@nabble.com designates 216.139.236.158 as permitted sender) Received: from [216.139.236.158] (HELO kuber.nabble.com) (216.139.236.158) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 30 Jun 2008 11:13:51 +0000 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1KDHKk-0005o1-MO for buildr-user@incubator.apache.org; Mon, 30 Jun 2008 04:14:10 -0700 Message-ID: <18193377.post@talk.nabble.com> Date: Mon, 30 Jun 2008 04:14:10 -0700 (PDT) From: Ittay Dror To: buildr-user@incubator.apache.org Subject: build dependency (was: Re: buildfile per component) In-Reply-To: <3de5d7d20806292230k691ccbm44546e6b2ca9c922@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: ittay.dror@gmail.com References: <18107287.post@talk.nabble.com> <3de5d7d20806271849k67c97823x7518cceeecb841f5@mail.gmail.com> <18167540.post@talk.nabble.com> <3de5d7d20806291210m5e14ac95r471a5bb5dc664b32@mail.gmail.com> <18185612.post@talk.nabble.com> <3de5d7d20806292112s62e18056ib9337ba5a7be692c@mail.gmail.com> <18188699.post@talk.nabble.com> <3de5d7d20806292230k691ccbm44546e6b2ca9c922@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org Assaf Arkin wrote: > > On Sun, Jun 29, 2008 at 9:56 PM, Ittay Dror wrote: >>> >> Which was what I was pointing to: I have modules foo and bar, foo depends >> on >> bar. If I write a single buildfile, then in foo's define I can reference >> bar >> with 'project(bar)'. If I split the build file so there are >> root/buildfile, >> root/foo/buildfile, root/bar/buildfile and build from root, everything >> works >> the same. But if I just want to build 'foo', I cd to foo and then buildr >> will pickup only root/foo/buildfile. Then, when it sees 'project("bar")' >> it >> will trigger an error, because it doesn't know bar (at least that is what >> I >> understand from looking at the source code). > > Let's say you have a buildfile for foo that's standalone. It > references artifacts built by bar, but it doesn't know about bar's > buildfile, projects, etc. Only that some artifacts (which bar happens > to produce) are necessary. It's possible to have a master buildfile > that can build both by including them from a parent directory. (I've > yet to try it myself, but looks like it will work) > > That way you can checkout foo and built it, or checkout bar and build > it, or checkout the parent and build both. > > Different thing if you want foo and bar to know about each other, > reference the projects, etc. Then both have to be part of the same > buildfile, conceptually. You can split a buildfile into as many small > files as you want, but they all have to load together. In this case > you have to check out the parent because building the parent would > require building foo and bar. > > Assaf > Fair enough and I agree with all your points. I do however have an idea which I wrote before but may have been obscured by the talk about separating build files: Today in buildr I have two modes: compile all and compile a project group (cd to the group's directory and run buildr) But, what if there are dependencies between modules and groups? Say I have an application with 'common', 'server' and 'client' modules (or group of modules). It would be nice if I could tell buildr to build 'server' and all its dependencies and it would build 'common'. or, if i cd into one of the server modules and build it, it will also build those modules in common which it depends on. this is good for source trees with high modularization (for example a framework that has a lot of plugins - it will be a waste of time to build everything just for one plugin). I know this may cause consistency problems ('common' might have changes that break 'client'), but I think the flexibility this brings is good (I know of one project that will benefit from such a feature). So, if in 'server' buildfile i use 'project("common")', and 'common' is not found in @projects, then buildr can try to load the buildfile from root/common. What is your view? Ittay Assaf Arkin wrote: > > >> >> So root/bar/buildfile should be evaluated also. >> >> There are two ways that I think of: >> 1. the "user" way: rename root/foo/buildfile and root/bar/buildfile to >> root/foo/buildfile.sub and root/bar/buildfile.sub. then when building in >> foo >> builr will still read the file from root/buildfile >> 2. the "framework" way: when referencing an unknown project, try to >> search >> the directories for a directory with the same name as the project and >> read >> the buildfile from there. this means buildr needs to know the root from >> which to search, maybe by requiring a root.buildr file to be placed >> there. >> then, if in root/foo/buildfile, buildr sees 'project("bar")', it will try >> to >> read root/bar/buildfile, finding the definition of bar there and all is >> well >> >> The second way is better for complex projects since it requires reading >> only >> those projects that are required as dependencies by the project that is >> currently being built. >> >> Unfortunately, I do not yet know enough Ruby / Rake / Buildr to try to >> attempt this change myself. >> >> Ittay >> >> >> Assaf Arkin wrote: >>> >>>> >>>> thanks, >>>> ittay >>>> >>>> >>>> Assaf Arkin wrote: >>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>> Assaf Arkin wrote: >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thank you, >>>>>>>> Ittay >>>>>>>> >>>>>>>> -- >>>>>>>> View this message in context: >>>>>>>> http://www.nabble.com/buildfile-per-component-tp18107287p18107287.html >>>>>>>> Sent from the Buildr - User mailing list archive at Nabble.com. >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> View this message in context: >>>>>> http://www.nabble.com/buildfile-per-component-tp18107287p18167540.html >>>>>> Sent from the Buildr - User mailing list archive at Nabble.com. >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> -- >>>> View this message in context: >>>> http://www.nabble.com/buildfile-per-component-tp18107287p18185612.html >>>> Sent from the Buildr - User mailing list archive at Nabble.com. >>>> >>>> >>> >>> >> >> -- >> View this message in context: >> http://www.nabble.com/buildfile-per-component-tp18107287p18188699.html >> Sent from the Buildr - User mailing list archive at Nabble.com. >> >> > > -- View this message in context: http://www.nabble.com/buildfile-per-component-tp18107287p18193377.html Sent from the Buildr - User mailing list archive at Nabble.com.