OBuild - parser errors

David Henshaw

Hi OT Gurus (particularly @Dave Carpeneto @Juliano_Ghisi @Hany Samuel @Stephan Baumann).

Working with OBuild, I've noticed something that I'm seeking guidance on whether this is a known issue/limitation, or whether perhaps some coding practices need review.

For quite some time, OScript has permitted referencing objects/functions using notation such as LLIAPI::APIObjects::PrgSession.GetPrgCtx. (I seem to recall a PPT similar to the old "Deep Dive" topics covering introduction, but cannot seem to find).

Alternately, a format $LLIApi.CacheUtil.Update is also valid.

I have a vague recollection that the first of these syntaxes when referencing objects is now the preferred way.

However, it appears that if the base Content Suite install that OBuild is connected to doesn't have the OSpace being referred to (using the first of these formats) installed/loaded that OBuild reports parse errors - but only where the relevant reference doesn't exist in the OSpace being built.

By way example, we have a module and it comprises a number of OSpaces - lets refer to these as "Master", "FunctionA" and "FunctionB".

This module is not installed in my base CS instance that OBuild is connected to.

I have a utility function declared in "Master" that is used by all three OSpaces.

In "Master", when I refer to this using MASTER::MasterUtils::Utils.FunctionX, OBuild is fine.

But when "FunctionA" or "FunctionB" utilise the same reference, OBuild will report something like:

OBUILD ERROR parseError Unknown object MASTER::MasterUtils::Utils : /tmp/src/modulename/FunctionA/utils.os : n : n: n

Ideally in my mind, the parser would check if the scope of the compilation being performed covers the reference.

The easiest fix is to replace references the MASTER::MasterUtils::Utils.FunctionX syntax with the equivalent $MASTER…. notation.

However, this in my view defeats purpose of using the "::" reference, which is to "trap" at compile time situations where a developer has made a reference to an invalid object - something the $ notation doesn't do (i.e. as incorrect references using this form are only identifiable at runtime!)

Are there any options in immediate term (other than changing reference format), or plans to address this going forward?

PS - my other goal with trying to standardise to the "::" reference notation is that longer term I want to look at scripting some form of check against the "OScript changes" file that OT produce for each release and that captures details of changed/added/removed objects. In fact this would be a great value add for OBuild, as you could report that as part of the build output so that the developer is advised of any references to core code being made and where it may be impacted by changes. In fact, this further in my mind cements the reason we should be using the "::" reference, as this would mean any reference to a removed object would result in a compile failure bringing those situations to attention, something the $ reference notation would "miss".

Regards,

David Henshaw

Fastman

Dave Carpeneto

Hi @David Henshaw - quick question: if you build this in CSIDE do things compile as expected? I'd guess the issue isn't OBuild-specific, since the underpinnings are largely identical WRT compilation, but thought I'd ask just in case.

FWIW the Global ( $ ) reference stuff is occasionally a convenience thing, but other times the two notations are in fact different. For example if I define "object x = a::b::c" as a global in OSpace X then by default "$X.x" and "X::a::b::c" are indeed the same thing. However what you'll see sometimes is code that will reassign $X.x to something else (such as a temp object / copy of X::a::b::c). Then the two references are different. This is why any funkiness appears at run-time instead of compile-time, as you flag - at compile time we cannot know 100% what "$X.x" will be in the future.

Having said all that: I'm too thick to follow the above example you provide to a point where I know what the root of the issue is / what can be done. If you'd like to go over things on a screen share please do reach out & I'll see what can be seen ( [email protected] ).

David Henshaw

Hi Dave,

Hope all is well - good to see you're still posting :)

Good question on the CSIDE front and whether builds there…..as usually to build any module, one would install it first, import the OLLs etc and then build - which implies the build environment knows about the objects being referenced.

So I uninstalled the module, restarted CSIDE and rebuilt from the oscript explorer.

This resulted in the OLLs being compiled and placed in the CS staging directory, but nothing else.

I've not tested the output to check works.

FYI the scenario here is simple - module has 3 OSpaces, the root ospace declares some utility functions that are used across by ospace. I have a variable assignement using one of these utility functions in the non-root ospace - e.g.

Assoc aDetailedPerms = FCSPERMMGR::FCSpermmgrUtils::Utils.PermMaskToStrings(iPermBitmask)

It's this bit that causes the parse error in OBuild. FYI, this was only recently added, prior builds all work as historically we used the $FCSPERMMGR reference approach.

Happy to have a call - I've got some other "wants" with OBuild. What's best time for you to catch up - I'll send invite :)

Regards

David