[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