lfc runtime troubles

[schoeberl]

I know it is working on other sides, but maybe someone has seen this issue before and can help me. I get a runtime error with lfc:

(base) luna:lingua-franca martin$ bin/lfc test/C/src/Minimal.lf 
1    [main] ERROR xt.validation.ResourceValidatorImpl  - The string resource '_UI_DiagnosticRoot_diagnostic' could not be located
java.util.MissingResourceException: The string resource '_UI_DiagnosticRoot_diagnostic' could not be located
        at org.eclipse.emf.common.util.DelegatingResourceLocator.delegatedGetString(DelegatingResourceLocator.java:542)
        at org.eclipse.emf.common.util.DelegatingResourceLocator.getString(DelegatingResourceLocator.java:446)
        at org.eclipse.emf.common.util.DelegatingResourceLocator.getString(DelegatingResourceLocator.java:561)
        at org.eclipse.emf.common.util.DelegatingResourceLocator.getString(DelegatingResourceLocator.java:553)
        at org.eclipse.emf.ecore.util.Diagnostician.createDefaultDiagnostic(Diagnostician.java:111)
        at org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:140)
        at org.eclipse.xtext.validation.ResourceValidatorImpl.validate(ResourceValidatorImpl.java:147)
        at org.eclipse.xtext.validation.ResourceValidatorImpl.validate(ResourceValidatorImpl.java:125)
        at org.eclipse.xtext.validation.ResourceValidatorImpl.validate(ResourceValidatorImpl.java:91)
        at org.lflang.cli.CliBase.validateResource(CliBase.java:107)
        at org.lflang.cli.Lfc.runGenerator(Lfc.java:235)
        at org.lflang.cli.Lfc.main(Lfc.java:181)

I am running on macOS with the following Java version:

java 17.0.5 2022-10-18 LTS
Java(TM) SE Runtime Environment (build 17.0.5+9-LTS-191)
Java HotSpot(TM) 64-Bit Server VM (build 17.0.5+9-LTS-191, mixed mode, sharing)

[edwardalee]

This works for me. Suggestions:

./gradlew clean
rm -rf test/C/src-gen
bin/build-lf-cli
bin/lfc test/C/src/Minimal.lf

[schoeberl]

Thanks for that suggestion, I originally tried to compile with ./gradlew assemble. With your proposal, I got a new error ;-) However, that one resulted from working on an LF clone from some years ago. After doing a clean checkout (with --recursive) all compiles now!

[schoeberl]

One more update: When building with ./gradlew assemble I still get an error when running lfc, but despite that error, lfc generates the C code. When building lfc with bin/build-lf-cli that error does not show up.

[cmnrd]

I only saw this now. I don't think that we configure the assemble task, so it might not work as expected. The prefered gradle task to build our cli tools is buildAll

[lhstrh]

Can we make assemble an alias of buildAll?

[cmnrd]

I don't know. I am also not a gradle expert and not sure which tasks would be expected by gradle users. Pinging @oowekyala on this one.

[oowekyala]

We could declare that assemble depends on buildAll easily, which is apparently the way to declare an "alias" in gradle. I'm not sure whether it is safe to do, since assemble actually also has its own dependencies and possibly actions. I can look into it today

[lhstrh]

Thanks, @oowekyala!

[oowekyala]

So from what I've seen the assemble task is actually the standard gradle task for assembling all outputs of a project. All subprojects, and the root project, have an assemble task. If you write gradle assemble it selects the task of the root project. By contrast, only the subproject org.lflang has a buildAll task, so if you write gradle buildAll it is expanded to gradle :org.lflang:buildAll.

The reason gradle assemble doesn't work properly here is that :org.lflang:assemble should depend on :org.lflang:buildAll (which is easily fixable). The thing is, gradle buildAll still just builds the org.lflang subproject, but not "all" the repo. By contrast, gradle assemble does build all the repo. It cannot be an alias for buildAll since it resolves to a task of the root project. Only the qualified name, (gradle :org.lflang:assemble) calls :org.lflang:buildAll.

I think we should fix the assemble task to work as gradle expects, and have an alias for calling :org.lflang:assemble. It could be called buildAll like now, but it feels weird because it doesn't build everything. Although maybe after #1276 it will make more sense.