Convert macros to rules and consolidate into one for Crashlytics by pswaminathan · Pull Request #20 · bazelbuild/tools_android

pswaminathan · 2025-11-11T16:14:42Z

This solves two things:

Previously we could not use select in e.g. package_name
This is useful for having one target across multiple environments. e.g. package_name = select({"dev": "com.my.app.debug"}) But because these were macros, select was not being evaluated.
Ergonomics of invoking multiple macros
Now there is a single thing to do in the build file. This also reduces duplication: previously you had to specify package name twice.

This would be a breaking change to consumers, so I'm wary of that. But I'm not sure how many others would feel this to be a regression, so I would love to hear feedback.

This solves two things: 1. Previously we could not use `select` in e.g. `package_name` This is useful for having one target across multiple environments. e.g. `package_name = select({"dev": "com.my.app.debug"})` But because these were macros, select was not being evaluated. 2. Ergonomics of invoking multiple macros Now there is a single thing to do in the build file. This also reduces duplication: previously you had to specify package name twice.

pswaminathan · 2025-11-11T16:14:42Z

This solves two things:

Previously we could not use select in e.g. package_name
This is useful for having one target across multiple environments. e.g. package_name = select({"dev": "com.my.app.debug"}) But because these were macros, select was not being evaluated.
Ergonomics of invoking multiple macros
Now there is a single thing to do in the build file. This also reduces duplication: previously you had to specify package name twice.

This would be a breaking change to consumers, so I'm wary of that. But I'm not sure how many others would feel this to be a regression, so I would love to hear feedback.

This solves two things: 1. Previously we could not use `select` in e.g. `package_name` This is useful for having one target across multiple environments. e.g. `package_name = select({"dev": "com.my.app.debug"})` But because these were macros, select was not being evaluated. 2. Ergonomics of invoking multiple macros Now there is a single thing to do in the build file. This also reduces duplication: previously you had to specify package name twice.

pswaminathan · 2025-11-11T16:14:42Z

This solves two things:

Previously we could not use select in e.g. package_name
This is useful for having one target across multiple environments. e.g. package_name = select({"dev": "com.my.app.debug"}) But because these were macros, select was not being evaluated.
Ergonomics of invoking multiple macros
Now there is a single thing to do in the build file. This also reduces duplication: previously you had to specify package name twice.

This would be a breaking change to consumers, so I'm wary of that. But I'm not sure how many others would feel this to be a regression, so I would love to hear feedback.

This solves two things: 1. Previously we could not use `select` in e.g. `package_name` This is useful for having one target across multiple environments. e.g. `package_name = select({"dev": "com.my.app.debug"})` But because these were macros, select was not being evaluated. 2. Ergonomics of invoking multiple macros Now there is a single thing to do in the build file. This also reduces duplication: previously you had to specify package name twice.

pswaminathan · 2025-11-11T16:14:42Z

This solves two things:

Previously we could not use select in e.g. package_name
This is useful for having one target across multiple environments. e.g. package_name = select({"dev": "com.my.app.debug"}) But because these were macros, select was not being evaluated.
Ergonomics of invoking multiple macros
Now there is a single thing to do in the build file. This also reduces duplication: previously you had to specify package name twice.

This would be a breaking change to consumers, so I'm wary of that. But I'm not sure how many others would feel this to be a regression, so I would love to hear feedback.

This solves two things: 1. Previously we could not use `select` in e.g. `package_name` This is useful for having one target across multiple environments. e.g. `package_name = select({"dev": "com.my.app.debug"})` But because these were macros, select was not being evaluated. 2. Ergonomics of invoking multiple macros Now there is a single thing to do in the build file. This also reduces duplication: previously you had to specify package name twice.

pswaminathan · 2025-11-11T16:14:42Z

This solves two things:

Previously we could not use select in e.g. package_name
This is useful for having one target across multiple environments. e.g. package_name = select({"dev": "com.my.app.debug"}) But because these were macros, select was not being evaluated.
Ergonomics of invoking multiple macros
Now there is a single thing to do in the build file. This also reduces duplication: previously you had to specify package name twice.

This would be a breaking change to consumers, so I'm wary of that. But I'm not sure how many others would feel this to be a regression, so I would love to hear feedback.

This solves two things: 1. Previously we could not use `select` in e.g. `package_name` This is useful for having one target across multiple environments. e.g. `package_name = select({"dev": "com.my.app.debug"})` But because these were macros, select was not being evaluated. 2. Ergonomics of invoking multiple macros Now there is a single thing to do in the build file. This also reduces duplication: previously you had to specify package name twice.

pswaminathan · 2025-11-11T16:14:42Z

This solves two things:

Previously we could not use select in e.g. package_name
This is useful for having one target across multiple environments. e.g. package_name = select({"dev": "com.my.app.debug"}) But because these were macros, select was not being evaluated.
Ergonomics of invoking multiple macros
Now there is a single thing to do in the build file. This also reduces duplication: previously you had to specify package name twice.

This would be a breaking change to consumers, so I'm wary of that. But I'm not sure how many others would feel this to be a regression, so I would love to hear feedback.

This solves two things: 1. Previously we could not use `select` in e.g. `package_name` This is useful for having one target across multiple environments. e.g. `package_name = select({"dev": "com.my.app.debug"})` But because these were macros, select was not being evaluated. 2. Ergonomics of invoking multiple macros Now there is a single thing to do in the build file. This also reduces duplication: previously you had to specify package name twice.

pswaminathan · 2025-11-11T16:14:42Z

This solves two things:

Previously we could not use select in e.g. package_name
This is useful for having one target across multiple environments. e.g. package_name = select({"dev": "com.my.app.debug"}) But because these were macros, select was not being evaluated.
Ergonomics of invoking multiple macros
Now there is a single thing to do in the build file. This also reduces duplication: previously you had to specify package name twice.

This would be a breaking change to consumers, so I'm wary of that. But I'm not sure how many others would feel this to be a regression, so I would love to hear feedback.

This solves two things: 1. Previously we could not use `select` in e.g. `package_name` This is useful for having one target across multiple environments. e.g. `package_name = select({"dev": "com.my.app.debug"})` But because these were macros, select was not being evaluated. 2. Ergonomics of invoking multiple macros Now there is a single thing to do in the build file. This also reduces duplication: previously you had to specify package name twice.

pswaminathan · 2025-11-11T16:14:42Z

This solves two things:

Previously we could not use select in e.g. package_name
This is useful for having one target across multiple environments. e.g. package_name = select({"dev": "com.my.app.debug"}) But because these were macros, select was not being evaluated.
Ergonomics of invoking multiple macros
Now there is a single thing to do in the build file. This also reduces duplication: previously you had to specify package name twice.

This would be a breaking change to consumers, so I'm wary of that. But I'm not sure how many others would feel this to be a regression, so I would love to hear feedback.

This solves two things: 1. Previously we could not use `select` in e.g. `package_name` This is useful for having one target across multiple environments. e.g. `package_name = select({"dev": "com.my.app.debug"})` But because these were macros, select was not being evaluated. 2. Ergonomics of invoking multiple macros Now there is a single thing to do in the build file. This also reduces duplication: previously you had to specify package name twice.

pswaminathan requested review from ahumesky and jin as code owners November 11, 2025 16:14

pswaminathan changed the title ~~Convert macros to rules and consolidate into one~~Convert macros to rules and consolidate into one for CrashlyticsNov 11, 2025