[CMake] [Repost] How to resolve conflicts between local and imported targets?

[Benedikt Hegner]

Hello,

A small correction to my previous post (see below). It should have  
read *local* target wherever I said *custom* target. Anyhow, the  
actual problem should remain the same:

I would need to have local targets override imported targets of the  
same name. And the only solution I a came up with would be patching  
cmMakefile.cxx. Before I go on asking for a feature addition to  
cmake, I'd like to know whether I can solve my problem by other means.

Any ideas?

   Benedikt


On Nov 24, 2010, at 12:17 PM, Benedikt Hegner wrote:

> Hello,
>
> I am facing a problem here on conflicts between imported targets  
> and custom targets. Basically I want to override an imported target  
> by a custom target of the same name. A solution like avoiding  
> clashes using NAMESPACE on EXPORT doesn't really work for me as the  
> identical naming is more or less intended (*). Still I've been  
> doing some gymnastics with using NAMESPACE and then 'importing'  
> single targets over into the local 'namespace' . That resulted in a  
> lot of fragile parsing-like code and just didn't work...
>
> So I ended up looking into the source code of cmake to see what's  
> going on under the hood. And a new policy like  
> ALLOW_OVERRIDE_IMPORT_TARGETS in cmMakefile would come handy  
> (wouldn't be too different from ALLOW_DUPLICATE_CUSTOM_TARGETS I  
> think). Giving it a quick shot it worked like a charm.
>
> Nevertheless I would hope to find a solution using already existing  
> functionality. Maybe you have an idea what to do instead.
>
> Thanks,
>   Benedikt
>
>
> (*)
> The use case is the following: we have a few hundred particle  
> physicists working on a software project with a few MLOC. To  
> facilitate the development we provide a hybrid environment - there  
> is one central installation with a fully built and installed  
> release. And then every user can set up a development area, check  
> out newer package-versions from the repository, which override the  
> ones in the central area, and do his development. At the moment  
> this is handled by a custom build tool which we plan to replace by  
> cmake. For cmake my current approach is having the central area as  
> one project that exports all its targets. And the development area  
> as another project importing these.
>