buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ittay Dror <ittay.d...@gmail.com>
Subject build dependency (was: Re: buildfile per component)
Date Mon, 30 Jun 2008 11:14:10 GMT



Assaf Arkin wrote:
> 
> On Sun, Jun 29, 2008 at 9:56 PM, Ittay Dror <ittay.dror@gmail.com> 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.


Mime
View raw message