SAVE INTO and differences between p-code vs cls-code

Posted by dbeavon on 19-Feb-2020 22:17

I'm working on fixing our compiler tooling for OpenEdge ABL projects.  

There was a problem related to the concurrent compilation into a shared working directory (one used by other active ABL sessions).  There is another separate post that discusses these concurrency conflicts : https://community.progress.com/community_groups/openedge_development/f/19/t/59721?pi20882=2

Now I'm using the SAVE INTO parameter as suggested by Frank Meulblok.  Here are the docs

https://documentation.progress.com/output/ua/OpenEdge_latest/index.html#page/dvref/compile-statement.html

The unfortunate thing I'm discovering about this approach is that p-code and cls-code are treated differently!  For cls-code, the compiler will create the missing directory structures and place compiled code in them once they are set in place.  However for p-code the compiler will *not* create the subdirectories and will simply generate error messages like the following (whereby the "app\Maintenance\Shipping" portion of the path wasn't created ahead of time).

Unable to create r-code file "C:\whatever\TempCompilation_v011\app\Maintenance\Shipping\FuelSurcharge.r". (477)

So it is unfortunate that I have to create my output directories ahead of time for some portions of the codebase and not others.  Here is the part of the docs that describes the behavior when compiling classes.  (it doesn't seem to apply to p-code) 

When you use the SAVE INTO phrase to store compiled r-code files for one or more class definition files 
specified with a package, ABL creates a directory structure under the specified SAVE INTO
directory that is consistent with the directory structure of the original source files relative to
PROPATH (if the directory structure doesn't already exist). That is, ABL creates a subdirectory
under the specified SAVE INTO directory to match the original source directory for
each class definition file in the hierarchy.

I'm assuming this difference in behavior is expected?  Is there a good reason for the difference in behavior between p-code and cls-code?  I'm assuming cls-code is more "strict" about matching folder structures and namespaces, so it takes the initiative to create folders.  Whereas the legacy p-code behavior is closely tied to PROPATH, and so it doesn't presume to know where you want your r-code saved.  Is that the idea?

Interestingly the XREF-XML output feature will create full directory structure and that does *not* seem to work differently for p-code vs cls-code.

When a directory is supplied, the compiler takes the root name of the procedure 
or class being compiled and creates a cross-reference file with this name 
and a .xref.xml file extension (sourcefilename.xref.xml). 
It stores it in the directory path specified, creating any 
necessary subdirectories that do not exist.

For now I will assume that I need to create all my own subdirectories in order for the "SAVE INTO" behavior to work for both p-code and cls-code.  

I think the approach I will use is probably to create empty directories with xcopy /t /e.  Please let me know if I'm using "SAVE INTO" incorrectly, or overlooking something in the COMPILE statement that will create my directories for me.

Here is is where xcopy is mentioned as a way to create directories:

https://superuser.com/questions/222310/copy-folder-structure-on-windows

Posted by Matt Baker on 20-Feb-2020 13:56

The difference is primarily due to the compilation of .p's preserves the legacy behavior from many many years ago.  The directory creation for .cls is as you have described: which is the path to the .cls is critical to its identify and how the AVM locates the .r code for it so the compiler will generate the correct folder structure.

The compilation tools such as PDSOE, PCT, and gradle plugins take care of this for you so you don't have to think about it.  The behavior you are describing is as expected. Can you take advantage of of these tools instead of building your own tooling?

You could add a feature request to have the behavior improved for.p files to the ideas website. openedge.ideas.aha.io/ideas

All Replies

Posted by Matt Baker on 20-Feb-2020 13:56

The difference is primarily due to the compilation of .p's preserves the legacy behavior from many many years ago.  The directory creation for .cls is as you have described: which is the path to the .cls is critical to its identify and how the AVM locates the .r code for it so the compiler will generate the correct folder structure.

The compilation tools such as PDSOE, PCT, and gradle plugins take care of this for you so you don't have to think about it.  The behavior you are describing is as expected. Can you take advantage of of these tools instead of building your own tooling?

You could add a feature request to have the behavior improved for.p files to the ideas website. openedge.ideas.aha.io/ideas

This thread is closed