Re: [Boost-build] Patch to fix dependency properties in project requirements

From: Jurko Gospodnetić (jurko.gospodnetic_at_[hidden])
Date: 2008-07-19 16:47:58

   Hi Steven.

>> #---------
>> project abla : id kuku ;
>> obj ooo : xxx.cpp ;
>> explicit ooo ;
>> exe xxx : kuku//ooo ;
>> #---------
>>
>>   Any thoughts on this?
> 
> I think that this is basically the correct fix.  It ought to
> be an invariant that if a project has an id attribute, this id
> must have been registered.
> 
> If I recall correctly
> exe xxx : kuku//ooo won't work, because project.find assumes
> that project ids start with /.  At the moment
> exe xxx : /abla/ooo ; ought to work, but not
> exe xxx : abla//ooo ; for instance.

   I just tested this and here are the results:

   exe xxx : ooo ;         # works fine.
   exe xxx : abla/ooo ;    # does not work.
   exe xxx : /abla/ooo ;   # works fine.
   exe xxx : kuku//ooo ;   # does not work.
   exe xxx : /kuku//ooo ;  # does not work.

   And changing the project id to /kuku makes no difference.

   Unfortunately I'm not really home with the ideas behind these project 
ids so I do not know what is the wanted behaviour. :-( Here are some 
thoughts/questions below.

   Is this the expected behaviour?

   Do we want to change this behaviour?

   Should this be changed so all these combinations are accepted?

   Should we expect project ids to be specified hierarchically starting 
from / like folders do? Or should we expect all project ids to live in a 
single global namespace?

   Are some sort of 'relative folder ids' allowed? What is the . or .. 
equivalent then?

   If some sort of 'relative folder ids' are allowed then how should 
they be expanded in features (like those dependency features your patch 
touches) to make them reference the same targets when applied in 
different folders.

   Best regards,
     Jurko Gospodnetić