[cmake-developers] [review] add_jar (UseJava) uses cmake_parse_arguments

Matthew Woehlke matthew.woehlke at kitware.com
Mon Mar 25 17:20:16 EDT 2013


On 2013-03-25 14:07, Brad King wrote:
> On 03/25/2013 01:46 PM, Matthew Woehlke wrote:
>> As is:
>> - Pros: add_jar accepts jars as it was apparently intended to, as
>> 'source' arguments
>> - Cons: maybe not optimal interface, must support this going forward
>
> Even after the proposed interface goes in we will still have to
> support the old-style interface whether it has this feature or not.

The 'current new' interface has not been in any release, has it? (There 
is not an rc2 yet, and I believe it was merged after rc1?)

> Users will be able to choose which style to use.  Having a way to
> get the dependencies in the old-style interface will be useful.
>
> So long as it is not too complicated to implement both interfaces
> once the proposed one is added I think we should go with this option.

In 2.8.10, there is no way to specify jar dependencies. In current 
master, they can be listed as sources. In the branch, INCLUDE_JARS is 
required.

I am not 100% sure I follow the above; do you mean you would prefer to 
accept jar dependencies without requiring INCLUDE_JARS even if support 
for INCLUDE_JARS were to land in 2.8.11?

(The main argument against would be that it is a behavior change versus 
2.8.10... but if you think it is a better interface, I would be okay 
with that.)

>> This branch:
>> - Pros: cleaner interface, stricter compatibility with 2.8.10
>> - Cons: non-trivial change, late in release cycle
>
> The new interface is complex enough that it should be more thoroughly
> reviewed and discussed by interested parties.

Mostly it is using cmake_parse_arguments instead of setting special 
variables prior to calling add_jar, but generally agreed...

Actually, there is a fourth option: I could write a patch that ONLY adds 
INCLUDE_JARS and doesn't touch the rest of the logic. This might be a 
more reasonable avenue for adding jar dependency support without 
changing the historic behavior.

-- 
Matthew




More information about the cmake-developers mailing list