project groups

[Ittay Dror <it...@gmail.com>]

Hi,

I have a situation where I have several components that use a set of 
common projects. To illustrate, assume components (projects) A and B use 
projects in 'common'. Now, what I would like to have is a way for a user 
to build component A or B, so that the 'common' projects are also built. 
The problem is that while all projects should be built, there's only 
runtime dependency (so I can't use compile.with).

I could make A:build depend on common:build, but this looks awkward 
(This is of course a toy example, in reality I have many components and 
many projects).

In general, the issue is that currently projects belong to just one 
group (one parent project) and I'd like a way to group them in other ways.

Any suggestions?

One thing that I thought of is to make recursive_task define 
dependencies on child projects, rather than on the parent project (as is 
the case today). Then, I could just add 'common' (defined before) to the 
list of 'projects' of A or B and then after_define of A will make 
A:build depend on common:build.

Thanks,
Ittay


-- 
--
Ittay Dror <it...@gmail.com>

Re: project groups

[Assaf Arkin <ar...@intalio.com>]

On Sun, Sep 21, 2008 at 5:29 AM, Ittay Dror <it...@gmail.com> wrote:
>
>
> Assaf Arkin wrote:
>>
>> On Wed, Sep 17, 2008 at 10:54 AM, Ittay Dror <it...@gmail.com> wrote:
>>
>>>
>>> Hi,
>>>
>>> I have a situation where I have several components that use a set of
>>> common
>>> projects. To illustrate, assume components (projects) A and B use
>>> projects
>>> in 'common'. Now, what I would like to have is a way for a user to build
>>> component A or B, so that the 'common' projects are also built. The
>>> problem
>>> is that while all projects should be built, there's only runtime
>>> dependency
>>> (so I can't use compile.with).
>>>
>>> I could make A:build depend on common:build, but this looks awkward (This
>>> is
>>> of course a toy example, in reality I have many components and many
>>> projects).
>>>
>>
>> Yep, that would be the right way to do it.
>>
>
> This is what I tried to do. The problem I'm having now is that while
> 'common' is conceptually part of A , A.projects doesn't return it, so
> generic code I have that iterates over sub projects doesn't pick on
> 'common'. Any suggestions?

Defines an array that collects all the projects that are conceptually
related and iterate over it.

Assaf

>
> Ittay
>
>> Assaf
>>
>>
>>>
>>> In general, the issue is that currently projects belong to just one group
>>> (one parent project) and I'd like a way to group them in other ways.
>>>
>>> Any suggestions?
>>>
>>> One thing that I thought of is to make recursive_task define dependencies
>>> on
>>> child projects, rather than on the parent project (as is the case today).
>>> Then, I could just add 'common' (defined before) to the list of
>>> 'projects'
>>> of A or B and then after_define of A will make A:build depend on
>>> common:build.
>>>
>>> Thanks,
>>> Ittay
>>>
>>>
>>> --
>>> --
>>> Ittay Dror <it...@gmail.com>
>>>
>>>
>>>
>>>
>
> --
> --
> Ittay Dror <it...@gmail.com>
>
>

Re: project groups

[Ittay Dror <it...@gmail.com>]

Assaf Arkin wrote:
> On Wed, Sep 17, 2008 at 10:54 AM, Ittay Dror <it...@gmail.com> wrote:
>   
>> Hi,
>>
>> I have a situation where I have several components that use a set of common
>> projects. To illustrate, assume components (projects) A and B use projects
>> in 'common'. Now, what I would like to have is a way for a user to build
>> component A or B, so that the 'common' projects are also built. The problem
>> is that while all projects should be built, there's only runtime dependency
>> (so I can't use compile.with).
>>
>> I could make A:build depend on common:build, but this looks awkward (This is
>> of course a toy example, in reality I have many components and many
>> projects).
>>     
>
> Yep, that would be the right way to do it.
>   
This is what I tried to do. The problem I'm having now is that while 
'common' is conceptually part of A , A.projects doesn't return it, so 
generic code I have that iterates over sub projects doesn't pick on 
'common'. Any suggestions?

Ittay

> Assaf
>
>   
>> In general, the issue is that currently projects belong to just one group
>> (one parent project) and I'd like a way to group them in other ways.
>>
>> Any suggestions?
>>
>> One thing that I thought of is to make recursive_task define dependencies on
>> child projects, rather than on the parent project (as is the case today).
>> Then, I could just add 'common' (defined before) to the list of 'projects'
>> of A or B and then after_define of A will make A:build depend on
>> common:build.
>>
>> Thanks,
>> Ittay
>>
>>
>> --
>> --
>> Ittay Dror <it...@gmail.com>
>>
>>
>>
>>     

-- 
--
Ittay Dror <it...@gmail.com>

Re: project groups

[Assaf Arkin <ar...@intalio.com>]

On Wed, Sep 17, 2008 at 10:54 AM, Ittay Dror <it...@gmail.com> wrote:
> Hi,
>
> I have a situation where I have several components that use a set of common
> projects. To illustrate, assume components (projects) A and B use projects
> in 'common'. Now, what I would like to have is a way for a user to build
> component A or B, so that the 'common' projects are also built. The problem
> is that while all projects should be built, there's only runtime dependency
> (so I can't use compile.with).
>
> I could make A:build depend on common:build, but this looks awkward (This is
> of course a toy example, in reality I have many components and many
> projects).

Yep, that would be the right way to do it.

Assaf

>
> In general, the issue is that currently projects belong to just one group
> (one parent project) and I'd like a way to group them in other ways.
>
> Any suggestions?
>
> One thing that I thought of is to make recursive_task define dependencies on
> child projects, rather than on the parent project (as is the case today).
> Then, I could just add 'common' (defined before) to the list of 'projects'
> of A or B and then after_define of A will make A:build depend on
> common:build.
>
> Thanks,
> Ittay
>
>
> --
> --
> Ittay Dror <it...@gmail.com>
>
>
>