lime icon indicating copy to clipboard operation
lime copied to clipboard

Project prebuild command is running too late

Open jobf opened this issue 6 months ago • 5 comments

I need to pre-process my assets for final builds so I have assets defined in a project.xml as follows. It will use game/assets for dev builds and game/assets-final for final builds -

<assets path="game/assets" rename="assets" unless="final" />
<assets path="game/assets-final" rename="assets" if="final" />

I have a script which I run to pre-process the assets, which will create the game/assets-final directory.

I wanted to run the script as a prebuild command in the project.xml -

<prebuild command="pre-process.sh" />

The problem is that lime's ProjectXMLParser will fail during project.xml parsing when it validates assets elements due to the directory not existing; Error: Could not find asset path "game/assets-final". This is because the assets elements validation occurs before the prebuild commands are executed.

To workaround this I could make sure that game/assets-final exists before doing a final build, however this isn't ideal.

So the question is, can we change the tooling to run the prebuild commands before fully parsing the project.xml? Or perhaps add a preparse command which would run before the parsing?

jobf avatar Jul 02 '25 13:07 jobf

can we change the tooling to run the prebuild commands before fully parsing the project.xml?

Changing when all <prebuild/> commands are run is probably too risky. It has the potential to break someone's existing workflow, if they somehow rely on project.xml being fully parsed.

Or perhaps add a preparse command which would run before the parsing?

<preparse/> wouldn't really be an accurate name since the element would be part of project.xml and can't be run until it itself is parsed.

Something like <prebuild noDelay="true"/> would probably be better, in my opinion (or maybe noWait, runNow, or runImmediately... not sure what the best name would be).

Personally, I feel like a final-build.sh that runs the pre-process.sh and then lime build is a perfectly reasonable solution.

joshtynjala avatar Jul 02 '25 16:07 joshtynjala

Personally, I feel like a final-build.sh that runs the pre-process.sh and then lime build is a perfectly reasonable solution.

Indeed, this is what I've ended up with and it's fine. Would still be cool to have it all handled by lime though 😎

Probably not worth the hassle anyway.

jobf avatar Jul 02 '25 16:07 jobf

What's going on here is that Lime has distinct "update" and "build" steps. Assets are processed during the update step, which must finish before the build step starts. <prebuild /> and <postbuild /> specifically run during the build step, hence the name.

I'm skeptical of <prebuild noDelay="true" />, because then it becomes unclear when it should and shouldn't run. If prebuild is no longer tied to lime build, what is it tied to? The implication is it runs every time the file is parsed, but that includes a bunch of cases that might not be appropriate. I can understand why you'd want it to run during lime update, but how about lime run? The file is parsed then, but no rebuilding is done. How about lime display, which is called in the background whenever the code completion server starts?

If we're going to do anything, I think the most consistent solution would be a <preupdate /> tag. Could go even farther and make the whole set (<predisplay />, <prerun />, and so on), but that feels like overkill.

player-03 avatar Jul 02 '25 18:07 player-03

If we're going to do anything, I think the most consistent solution would be a tag.

This feels like the cleanest and most targeted way to do what @jobf wants. By tying it specifically to the "update" step of Lime, I'm actually more inclined to think that it makes sense to add than I did before.

Could go even farther and make the whole set (, , and so on), but that feels like overkill.

Agreed on the overkill.

joshtynjala avatar Jul 02 '25 18:07 joshtynjala

Reading this again, it occurs to me that this wouldn't be an issue if using the HXP format. Those are all code, so you can execute arbitrary code whenever the file is parsed. The downside is, it would run more than needed, but if "create directory if it doesn't exist" is simple enough that you probably wouldn't notice. And for slower operations, you could put it in an if statement.

My thought is, if HXP can do it, why not XML?

<execute command="mkdir game/assets-final" result="mkdirResult" if="final" unless="display" />
<error value="Encountered an error while creating game/assets-final" if="${mkdirResult}!=0" />

player-03 avatar Oct 23 '25 00:10 player-03