Add support for specifying APT options.

[justhecuke-zz]

We need to be able to pass -Adagger.fastInit=enabled to the underlying javac.

This is a very common for Android builds since it makes the critical path faster resulting in a snappier UX.

[cgruber]

This actually needs, more generally, to allow for annotation processor options to be passed in to kt_jvm_library/binary targets, either by passing javac_opts, or something like kapt_opts.

[justhecuke-zz]

It doesn't require a general solution. It can be done as a specific attribute flag in the toolchain like the other existing compiler options that are supported.

A general solution would, of course, also solve this, but it isn't specifically required.

I made a separate issue for this since the other issue open is for the general solution which I don't require at this specific moment.

On Wed, Jan 22, 2020, 9:32 AM Christian Edward Gruber < [email protected]> wrote:

This actually needs, more generally, to allow for annotation processor options to be passed in to kt_jvm_library/binary targets, either by passing javac_opts, or something like kapt_opts.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/bazelbuild/rules_kotlin/issues/262?email_source=notifications&email_token=ABRBPZJJGGBVAAFHBXEDTZLQ7B7KNA5CNFSM4KJ6D2Q2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJUN7SQ#issuecomment-577298378, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABRBPZMDSQZWAF4TQK57UQ3Q7B7KNANCNFSM4KJ6D2QQ .

[cgruber]

Ahhh. I see. You're seeing this as a global toolchain-level config to pass through, not a per-target. Ultimately both are needed, I think, based on my experience with Google and annotation processors and configuration, but we can probably get the toolchain part in pretty quickly.

[benjaminRomano]

I'm also running into this. I'd like to add on the following dagger options.

-Adagger.fastInit=enabled
-Adagger.formatGeneratedSource=disabled
-Adagger.experimentalDaggerErrorMessages=enabled

Is this something the discussion here would resolve?

[Bencodes]

@benjaminRomano yes it hopefully should. I'd encourage you to cross post your use case in the other thread so that it's accounted for in what ever solution we land on.

[cgruber]

I don't think it will because of this. To summarize, kotlinc compiler options are not kapt arguments, exactly, and there's a bunch of kapt-specific interop issues with java rules that we have to treat separately. I absolutely think the time is now to solve the apt options issue, so folks can configure dagger, and we'll prioritize it. But it is a different (though overlapping) problem from kotlinc flags, and will need separate treatment.

[cgruber]

Note for design - we need to be able to specify APT options, but also parse out -A options that were given in java_plugin() rules, which should be applied to every invocation that is configured to consume that plugin.

[BenHenning]

I came across this issue when trying to investigate why Werror being set both globally (via javacopts) and via kt_javac_options wasn't actually causing a build warning caused by Dagger-generated code to trigger a build error. Would introducing APT options include solving this case? If not, should I file a separate issue for it? It's rather unfortunate that 'Werror' doesn't actually catch all warnings. :)