OBuild - parser errors

David Henshaw · November 20, 2023

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 · November 21, 2023

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 ( dcarpene@opentext.com ).

David Henshaw · November 21, 2023

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

HFCDev · December 11, 2023

Dave/David,

I took David's docker file to try this out. I'm getting similar results when I try to build our module which similarly depends on a lot of OSPACE::Pkg::Function() type code (although with 10+ years of legacy code, there are a lot of $ notations as well). I too have a module with multiple ospaces, and in my case, it crashed building one of the dependent ospaces (you'd think it would try to build the least dependent one first). This module builds fine in Eclipse on a proper CS environment.

-Hugh

Dave Carpeneto · December 11, 2023

Hi Hugh - sorry to hear you're bitten by this as well. Wile we wait for investigation to return some news over here: is there any option for you to try either of the following to see if the outcome shifts? :

A) change the order in the [OSpaces] section of your module's ini?

B) separate the OLL out into its own module, which the other OSpace would then have a dependency on?

… no clue if either of these alter the outcome, but thought I'd ask / suggest, in case this does something :-)

HFCDev · December 11, 2023

The strange thing is that the first ospace in the list is the one that it cannot find. The ospace reporting the error is #4 in the list. So I don't think changing the order will affect the outcome.

Dave Carpeneto · December 11, 2023

Well that rules the first one out ;-). Worth a shot. I'll try to investigate this one as well, however I'm not "the OBuild guy" …

David Henshaw · December 11, 2023

Hi Dave - seconding Hugh's observation. Our INI file has the root module OSpace listed first in the [OSpaces] section, with the reference to the function (in that root ospace) being made from a ospace listed later in order.

PS - re splitting into separate modules. Not an option for us I'm afraid - historically we used to do just that, so we could manage access to functionality etc. When we introduced license keys some years back, we consolidated the related modules into one module (with multiple ospaces). This eases deployment and management on customer side. I doubt from what we're seeing it would make a difference either, I suspect the parser will still report that it can't resolve the reference.

HFCDev · December 11, 2023

I will second David's PS. The partner I'm working for used to have separate modules but in 2020 decided to consolidate them all so there is one install, one restart to do instead of multiples. This was found to be much better for the clients. If the module were packaged as part of core, separate modules would be an option but when it's a separate installation, making life easier for the customer is always the best decision.

-Hugh

OBuild - parser errors

Answers

Categories