Skip to content

Allow specifying a custom generated header name#350

Closed
segiddins wants to merge 6 commits intobazelbuild:masterfrom
segiddins:segiddins/generated-header-name
Closed

Allow specifying a custom generated header name#350
segiddins wants to merge 6 commits intobazelbuild:masterfrom
segiddins:segiddins/generated-header-name

Conversation

@segiddins
Copy link
Contributor

This is my first time contributing to this repo, and I couldn't find any guidelines on where or how to add tests.

This is an attempt to implement #346

@googlebot
Copy link

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.


What to do if you already signed the CLA

Individual signers
Corporate signers

ℹ️ Googlers: Go here for more info.

@segiddins
Copy link
Contributor Author

segiddins commented Nov 7, 2019

(Working on getting added to our CLA google group)

CLA should be handled

@segiddins
Copy link
Contributor Author

@googlebot I signed it!

@googlebot
Copy link

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

@googlebot googlebot added cla: yes and removed cla: no labels Nov 7, 2019
"generated_header_name": attr.string(
doc = """\
The name of the generated Objective-C interface header.
If not provided, defaults to `${target_name}-Swift.h`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The markdown documentation needs to be updated too. I think it's not auto-generated for now.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's generated, just with a script that we run internally (because it's a bunch of hacks held together with chewing gum that we don't want to publish). Now that Stardoc has come farther along, it may be viable to switch over to.

tl;dr: don't worry about updating the docs in this PR, we'll regenerate them.

"generated_header_name": attr.string(
doc = """\
The name of the generated Objective-C interface header.
If not provided, defaults to `${target_name}-Swift.h`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's generated, just with a script that we run internally (because it's a bunch of hacks held together with chewing gum that we don't want to publish). Now that Stardoc has come farther along, it may be viable to switch over to.

tl;dr: don't worry about updating the docs in this PR, we'll regenerate them.

@segiddins segiddins force-pushed the segiddins/generated-header-name branch from 26230fa to 7469a85 Compare December 3, 2019 18:24
@googlebot
Copy link

All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter.

We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only @googlebot I consent. in this pull request.

Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the cla label to yes (if enabled on your project).

ℹ️ Googlers: Go here for more info.

@googlebot googlebot added cla: no and removed cla: yes labels Dec 3, 2019
@segiddins
Copy link
Contributor Author

@allevato I think the CLA bot is complaining because of your commit via suggested changes

@allevato
Copy link
Member

allevato commented Dec 6, 2019

Yeah, you could work around that by squashing (I don't need to retain authorship of the suggestions) but since I have to pull the commit internally anyway to test it ultimately won't matter.

Sorry for the delay on this—I've been in an internal team event all week, so I'll likely take a look at this on Monday.

@segiddins segiddins force-pushed the segiddins/generated-header-name branch from 7469a85 to 3b51def Compare December 19, 2019 01:08
@thii
Copy link
Member

thii commented Jan 8, 2020

Can we have this landed on the next release? :)

@ob
Copy link
Contributor

ob commented Jan 10, 2020

Any updates on this?

Copy link
Member

@thii thii left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Found some errors when trying this patch (the validation always failed).

return actions.declare_file("{}-Swift.h".format(target_name))
if header_name:
if not header_name.endswith(".h"):
fail(("The generated objc header name for {} must end in" +

This comment was marked as resolved.

fail(("The generated objc header name for {} must end in" +
" '.h', given '{}'") % (target_name, header_name))
if header_name.find("/"):
fail(("The generated objc header name for {} cannot contain a " +

This comment was marked as resolved.

Co-Authored-By: Thi <t@thi.im>
@allevato
Copy link
Member

Sorry for the delay on this; in addition to being stretched a bit thin right now, I've been in the middle of refactoring these rules to support some future work that we need. I'll look at adding this change in as part of that so that you don't have to rebase it in on top of a completely changed implementation.

@kastiglione
Copy link
Contributor

@allevato I was wondering with Keith what was driving the refactoring. Are you able to comment on the referenced "future work"?

@allevato
Copy link
Member

@allevato I was wondering with Keith what was driving the refactoring. Are you able to comment on the referenced "future work"?

The old design was based around the assumption that the only action we cared about was SwiftCompile. When I prototyped the support to integrate PCMs into the dependency graph, it became clear that there were places where I collected info from providers where I'd need different subsets of flags/input files for the -emit-pcm action vs. the compile action, and trying to parameterize those functions to say "do these things but not these things" didn't scale at all.

By refactoring the actions to be more granular, adding PCM actions will be cleaner because all I'll have to do is add the PCM action name to the appropriate subset of action configurators, and then wire in the action itself.

It'll also pave the way for other improvements we've talked about but had to put off, like splitting out module compilation vs. object compilation.

@kastiglione
Copy link
Contributor

thanks!

swiple-rules-gardener pushed a commit that referenced this pull request Jan 30, 2020
Co-authored-by: Samuel Giddins <segiddins@users.noreply.github.com>

Closes #350.

RELNOTES: None.
PiperOrigin-RevId: 292413600
swiple-rules-gardener pushed a commit that referenced this pull request Jan 31, 2020
Co-authored-by: Samuel Giddins <segiddins@users.noreply.github.com>

Closes #350.

RELNOTES: None.
PiperOrigin-RevId: 292413600
tymurmustafaiev pushed a commit to tymurmustafaiev/rules_swift that referenced this pull request Jul 19, 2023
Co-authored-by: Samuel Giddins <segiddins@users.noreply.github.com>

Closes bazelbuild#350.

RELNOTES: None.
PiperOrigin-RevId: 292541776
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants