GN: Remove stale generated file?

[Jamie Madill]

I am in the process of updating my build files for a third party repo. The repo switched from auto-generating a certain file to including a static version in the repo. However, the "stale" version of the header is being pulled in from another generated file, instead of getting the correct static file, and compilation is failing.

This is an issue because every developer will suffer the same fate on an update (and potentially every bot, if they don't clean the entire generated directory every compile).

Has anyone run into this problem before with GN? Is there a recommended practice for doing this? Is there even a way in GN to delete files if they exist already?

[Dirk Pranke]

You can use landmines, but that's a really big hammer.

I don't think we have a good way of dealing with this, otherwise.

Since we theoretically know about all of the files that will be generated at GN-time, conceivably we could do something like write them out to a file and then if the list changes, delete the ones that are gone. That seems like a potentially good idea, but perhaps someone can shoot holes in it?

-- Dirk

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CACOTusRcr5HK%3DkwgONZ1tHg3DjN4E4KH4wV4bCbB6SJE8U0M-g%40mail.gmail.com.

[Jamie Madill]

Seems like a good long-term solution. In the meantime I can make a small python script invoked by an action step to handle this particular file.

[Scott Graham]

Perhaps just using a different basename for the header would be a simple/hacky workaround too.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CACOTusQ2dTjo%3Dai%2BkJGUVUuebopd6oXZD02Hop2NaHepnvaxTA%40mail.gmail.com.

[Jeremy Randolph]

Get Outlook for Android

---

From: Scott Graham <sco...@chromium.org>
Sent: Wednesday, December 13, 2017 3:49:53 PM
To: Jamie Madill
Cc: Dirk Pranke; chromium-dev; Brett Wilson
Subject: Re: [chromium-dev] GN: Remove stale generated file?

 

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CANHK6RbK9%2BLD2tK5uVFJMNn-R5%3D%2B3xPnv9aV%2Ba-zscQyLGsOEg%40mail.gmail.com.

[Primiano Tucci]

$0.02 from a random observer passing by.

I recently started working on a project that uses both GN and Android's Soong .

Soong seems to have some checks that ensure that a target is actually generating the headers it depends on to avoid the situation described above. it requires a target to list the generated_headers (Example).

I don't know how it works under the hoods. I *guess* it looks at the transitive includes emitted by the compiler for each translation unit and, for includes in the output folder, it checks that the target depends on a gen rule that has that header listed in the output section.

Maybe GN could do something similar? IIRC it already gets the transitive #includes when checking dep rules via `gn check`.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/BY1PR0601MB1418BB9127552665D0111453F1350%40BY1PR0601MB1418.namprd06.prod.outlook.com.

[Dirk Pranke]

On Thu, Dec 14, 2017 at 5:24 AM, Primiano Tucci <prim...@chromium.org> wrote:

$0.02 from a random observer passing by.

I recently started working on a project that uses both GN and Android's Soong .

Soong seems to have some checks that ensure that a target is actually generating the headers it depends on to avoid the situation described above. it requires a target to list the generated_headers (Example).

This attacks a slightly different problem, though, right? This wouldn't by itself do anything to delete a previously generated file that should no longer be used. 

-- Dirk

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CANHK6RbK9%2BLD2tK5uVFJMNn-R5%3D%2B3xPnv9aV%2Ba-zscQyLGsOEg%40mail.gmail.com.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

[Michael Giuffrida]

+1 to solving this problem.

I had a similar issue recently, minus the third-party repo. I had moved a .proto file and simultaneously added fields to the proto, so a new header file was being generated in the new location within the out/Debug/gen directory. But my attempts to use the new fields (ie, the new code that should have been generated) were met with compiler errors.

The issue was that some files were still #include'ing the header from the old location, which succeeded without errors because the old generated file still existed. If old generated files stick around, you might be compiling against something whose source doesn't even exist anymore. Worst case, you'll only find an issue when your CL mysteriously fails on the trybots.

- Michael

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAEoffTDJ_KrWTHQZBzGSVbpKbecvp5yHuhOPh6BEZyhEsU_1Lg%40mail.gmail.com.

[Tomasz Śniatowski]

On Fri, Dec 15, 2017 at 12:56 AM, Dirk Pranke <dpr...@chromium.org> wrote:

On Thu, Dec 14, 2017 at 5:24 AM, Primiano Tucci <prim...@chromium.org> wrote:

$0.02 from a random observer passing by.

I recently started working on a project that uses both GN and Android's Soong .

Soong seems to have some checks that ensure that a target is actually generating the headers it depends on to avoid the situation described above. it requires a target to list the generated_headers (Example).

This attacks a slightly different problem, though, right? This wouldn't by itself do anything to delete a previously generated file that should no longer be used. 

-- Dirk

 

Correct. However, it does tell us we're some distance away from knowing, at GN time, about "all of the files that will be generated" -- and that's only for compile steps and actions that properly use depfiles.

I'm fairly certain there are places that work like so:

* Target T1 generates files F1 and F2, but only lists F1 as outputs

* Target T2 deps on T2 and uses F1 and F2, but only has F1 in inputs

Doing any partial clean in cases like these seems a bit risky. If only T2 needs to be rebuilt and we delete F2, things might explode.

Maybe if we only deleted files previously-known to be generated it'd be better... but generally deleting parts of the outdir seems iffy.

You received this message because you are subscribed to a topic in the Google Groups "Chromium-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/chromium-dev/hTshXfq3Q9M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to chromium-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAEoffTAMuEygSOtKF42tkXFAN_%2BRu2x488qMG2-yB94t8PftLg%40mail.gmail.com.