Re: [jamboost] PATCH: project default build interacts unexpectedly with multiply defined main targets

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-07-24 08:25:21

Hi Michael,

Michael Stevens wrote:

> For a long time I believed that multiply defined main targets didn't
> work. Finally I have tracked the problem down to an interaction with
> project build defaults.
>
> At present the following will unexpectedly (for me at least!) fail with
> the error "default build can be specified only in first alternative".
>
> project : : default-build debug ;
> lib zlib : : <name>z <variant>release ;
> lib zlib : : <name>z_d <variant>debug ;

Oops. Unexpected for me, too.

> The problem is that this is equivilent to
>
> lib zlib : : <name>z <variant>release : debug ;
> lib zlib : : <name>z_d <variant>debug : debug ;
>
> which is explicitly disallowed. Only the first definition is allowed to
> define a default build.
>
> It seems logical that the above two definitions should be identical.
> Therefore I think the best fix is to weaken the current check. Instead I
> propose that the default builds must be identical in multiple main
> target definitions.

Hmm... that would require more typing. OTOH, the current behaviour is not 
right either. Maybe, it's better to allow subsequent targets to either not 
specify default build or specify exactly the same? 

Just a though, though --- the semantic you propose is fine with me, too.

> The following patch implements this weaker check and modifies the error
> message appropriately.

Thanks for the patch! 

> Weaken multiple main target default build check. Must be identical
> rather then only defined on first.
>
> RCS file: /cvsroot/boost/boost/tools/build/new/targets.jam,v
> retrieving revision 1.106
> diff -U3 -r1.106 targets.jam
> --- targets.jam 21 Jul 2003 08:30:19 -0000 1.106
> +++ targets.jam 24 Jul 2003 09:57:34 -0000
> @@ -374,15 +374,17 @@
> rule add-alternative ( target )
> {
> local d = [ $(target).default-build ] ;
> - if $(self.alternatives) && [ $(d).raw ]
> + if $(self.alternatives) && ( [ $(self.default-build).raw ] != [
> $(d).raw ] )

Some nits. You don't have to call "raw" to compare property-sets. Just

$(self.default-build) != $(d) 

should suffice. Another nit: is that your mailer has wrapped the patch ;-) 
Probably, attachement will be safer. Last nit: when your patch is applied,
the "default_build" test no longer passes :-) Not a big surprise, since we 
check for the current logic. 

If you have some time to to run the test and change it, that would be great. 
Of course, if you don't have the time right now, I'll be happy to apply the 
patch and change the test myself.

Thanks,
Volodya