R.swift: R.generated.swift is not re-generated without a clean build on 5.0.0 final

Created on 4 Jan 2019  路  15Comments  路  Source: mac-cain13/R.swift

Hi!

I was using R.swift 5.0.0-alpha2 and had a unit test running validate() which was correctly failing whenever I had a wrong asset or font in a XIB:

XCTAssertNoThrow(try R.validate())

I've just updated to 5.0.0 and checked if that was still working before merging this update, but the test now passes for the same incorrect asset/font that fails the test at 5.0.0-alpha2.

Am I doing this in a deprecated way or is the feature broken?

Thanks!

Most helpful comment

R.swift 5.0.2 has been released, so I'm closing this issue.

From the updated migration documentation:

When using the New Build System:
Configure the input/output files

When using the Legacy Build System:
Add the flag --disable-input-output-files-validation
Do not configure input/output files

If you're still experience issues after upgrading to 5.0.2, please create a new issue.

All 15 comments

Sounds like a bug, the way to validate is not changed. Could you give the latest stable release a try to see if it is working or not?

Are all validation checks failing or just a specific one?

Hi @mac-cain13 ! Thank you for your timely answer, and I'm sorry I took days to answer you back.

So, actually, after additional tests, I guess this is a cache issue introduced to R.swift very recently.

I am using the latest README instructions which recently changed the shell script and now require input files and output files to be specified, I have a suspicious that this is related.

鉃★笍 On 5.0.0-alpha2 I tried replacing this:

<customFonts key="customFonts">
        <array key="Politica-Bold.ttf">
            <string>Politica-Bold</string>

by this:

<customFonts key="customFonts">
        <array key="Politic-Bold.ttf">
            <string>Politic-Bold</string>

and validate() did not throw any exception.

鉃★笍 2nd attempt: I replaced this:

<fontDescription key="fontDescription" name="Politica-Bold" family="Politica" pointSize="15"/>

by this:

<fontDescription key="fontDescription" name="Politic-Bold" family="Politic" pointSize="15"/>

again, no exception.

鉃★笍 3rd attempt: I replaced this:

<state key="normal" image="Previous"/>

by this:

<state key="normal" image="Previou"/>

again, no exception.

鉃★笍 4th attempt: I replaced this:

<image name="Next" width="14" height="24"/>

by this:

<image name="Nex" width="14" height="24"/>

and this time it did throw an exception :muscle:
"[R.swift] Image named 'Nex' is used in nib 'PlayerControllerView', but couldn't be loaded."


Then I kept the same 4 changes and simply updated to 5.0.0 final, the very same exception was thrown. I reverted my 4th change and to my surprise, again it threw that exception 馃槺

Next, I did a full clean, ran the unit test again and the exception was gone this time (so, identical to 5.0.0-alpha2). Then I reapplied the 4th change and still no exception (this is contrary to 5.0.0-alpha2 where I got the exception right after applying the 4th change, without any cleaning in between).

And finally, just to be safe, I cleaned again and re-run the test with the same 4 changes, and this time it did throw the expected exception, meaning 5.0.0's validate() works identical to 5.0.0-alpha2's as long as you clean the build before running it.


Fonts and images are everything I currently use R.swift for, so I can't be sure about other scenarios where validate() should throw an exception.

Hmm, strange, thanks for the tests and explanation. Few questions that come to mind:

  • Change 1 and Change 2 are breaking a font in a xib right? This is not checked by validate. Would be a nice addition, but for now we only check if the TTF can be loaded from code.

  • Change 3: I'm not sure the state key="normal" is checked at all. Think we never implemented this to be picked up by R.swift. Do you see the Previous image mentioned in the validate implementation?

  • Change 4: This is validated, so this is a good test case indeed. If you look at the validate implementation R.swift generates, do you see code changes when building _without_ cleaning? It sounds as if R.swift is not runned and your project is not recompiled when you rerun the tests. (Renaming Next to Nex should change code in the generated file.)

Yeah, after renaming and re-running the unit test, the image was still named Next in R.generated.swift, so indeed it looks like this file is not being re-generated on 5.0.0 for me without cleaning the project. If I do the other way around, R.generated still says "[R.swift] Image named 'Nex' is used in nib ... after renaming to Next.

Does that sound like a project-specific issue or can you confirm that 5.0.0 works fine in another project? Thanks a lot!

Same problem here in 5.0.0 version.

Found the same problem. As a work-around, I added a second output file named R.dummy.swift which is never present and forces the script to always run.
PS: I'm using the legacy build system because of other issues with development pods, I'm not sure if this changes behaviour with R.swift in any way.

Thanks guys! I鈥檓 also using the legacy build system, just in case 馃憤

Have you added $TEMP_DIR/rswift-lastrun to the "Input Files" and $SRCROOT/R.generated.swift to the "Output Files" of the Build Phase? Asking because that should make sure R.swift is triggered at every build.

I do not completely understand why adding R.dummy.swift like @rafaelnobrepd did should fix it, because the lastrun file should already take care of this. Unless this is a problem with the old build system, I think we're using the new build system for all our projects already.

I have to find some time to look into this, or if anyone could confirm this is an issue with the old build system and it works fine with the new build system that also would really help.

@mac-cain13 yep, I have it all set up as per latest README.

Just tried it using the New Build System and indeed this time R.generated.swift did get re-generated. Great guess @rafaelnobrepd !

Also, for the first time I didn't have Pods issues with the New Build System, perhaps because I've updated a bunch of Pods or because the last time I did it was on Xcode 10.0 (I've got 10.1 now), so I guess I'm just going to stick with R.swift 5.0.0 and the New Build System :)

Okay, so it seems the old build system behaves differently and does not run R.swift on the correct moments in the current setup. Need some investigation to see why that is and how to fix it.

I guess that removing all the input/output files from the build phase would work, but R.swift 5 checks these input/outputs so then it will refuse to run.... :(

it would be nice to have confirmation from either @fernandocruz or @rafaelnobrepd that the new build system allows R.swift 5 to re-generate its file, just to be sure that this is indeed the cause.

Same issue here using the legacy build system

Development Pods + R.Swift + Legacy Build System != <3
R.Swift doesn't recreate R file
馃槥
Development Pods + R.Swift + New Build System != <3
Development pods don'y recompile
馃槥

The current R.swift version (5.0.1) indeed doesn't work correctly with the Legacy Build System.
I've created a PR (https://github.com/mac-cain13/R.swift/pull/482) to add a flag to disable validation, so R.swift _can_ be used with the Legacy Build System. This should be released soon as version 5.0.2.

As far as I know, the current version of R.swift should correctly work when using the New Build System, including with development pods. If you have a concrete example of where something goes wrong, could provide a reproduction path?

R.swift 5.0.2 has been released, so I'm closing this issue.

From the updated migration documentation:

When using the New Build System:
Configure the input/output files

When using the Legacy Build System:
Add the flag --disable-input-output-files-validation
Do not configure input/output files

If you're still experience issues after upgrading to 5.0.2, please create a new issue.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Horse888 picture Horse888  路  5Comments

darecki picture darecki  路  4Comments

tomlokhorst picture tomlokhorst  路  5Comments

alexpersian picture alexpersian  路  6Comments

tomlokhorst picture tomlokhorst  路  6Comments