Subscribe via RSS
Toggle Submenu
  1. Categories
  2. Recent
  3. Tags
View Replies (4)

Resolved Folder for compiler's C++ files?

  1. How-to
1
Votes
Undo
  1. Michael Kramer
    Michael Kramer
  2. PowerBuilder
  3. Wednesday, 11 March 2020 13:27 PM UTC

Environment variable defines TEMP file folder for PB's machine code compiler. I forgot its name.

UPDATE => Found it! 
It is config parameter in PB.INI, section = [PB], name = CODEGENTEMP.
I used ProcMon from Sysinternals to investigate the PB compiler DLL's text content and found the name "hiding in plain sight".

I found:

  • File = cgq72bu6.c (and name siblings) created for different classes in Tiny.PBL and Export.PBL
  • Same for file = cgq72bu8.c and cgq72bu7.c - and more...
  • They come in different order within each PBL.
  • No duplicate class names in my source.

WHY reuse temp file name?

Unless there is an option to suspend PB's process during compilation when files are created but not yet deleted I will have to monitor all file system activity in the TEMP folder and copy all *.c files within a 200 msec timespan of its latest change before compiler deletes it and possibly creates new file of same name. Same C-file may be refreshed several times after creation before deletion. Those changes may be separated by much longer timespans  than from last change to deletion.

So any automation I create risks copying *.c files to a "safe haven" multiple times - sometimes based on same class  - sometimes on other classes. SO it has to look into each file's content to determine what class is implemented. This feels tedious and feels like there may be an easier way.

Anyone knows easier way to capture all generated *.c files?
Without writing a FileSystemWatcher class and complete file processing in sub-sub-seconds response times.

Other environment variables that may influence compiler behavior?

TIA /Michael

  1. Compiler
TreeView - Linking Table Makes Duplicates
Data Field AutoSize Height Property
Responses (4)
Roland Smith
Roland Smith Accepted Answer Pending Moderation
  1. Friday, 13 March 2020 14:14 PM UTC
  2. PowerBuilder
  3. # 1

Why do you need to capture the C++ files?

Comment
Michael Kramer
  1. Michael Kramer
  2. Friday, 13 March 2020 14:35 PM UTC
I want to investigate the generated C++ code for several reasons:

* To do security reviews/vulnerability checks

* To learn how the C++ code looks; especially to learn how good a security layer machine code generation really is.

* I'm curious
  1. Helpful
There are no comments made yet.
Michael Kramer
Michael Kramer Accepted Answer Pending Moderation
  1. Friday, 13 March 2020 09:42 AM UTC
  2. PowerBuilder
  3. # 2

Hey Brad, This failed for me due to NTFS permissions. Compiler requires file renaming - which requires ALLOW:DELETE. To avoid losing the .C files I had to DENY:DELETE; so compilation failed.

 

Chris?

  • How do get PB to keep the temporary .C files during machine code generation? 
  • Do you actually have one file for each PB class? (see below)
  • Have you seen your techniques work on PB 2019 R2?

 

My current working solution - albeit incomplete for the moment:

  • Use CODEGENTEMP to control which folder receives all compiler temp files
  • Write .NET Core 3.1 app to monitor that folder and react on file changes
  • .NET has excellent FileSystemWatcher for this exact requirement
  • I monitor for Changed files where name = *.?    -- ex: *.c or *.h
  • I copy every file to separate Backup library whenever a file changes.

But this is half-baked solution because same filename contains different class within timespan of a second or so. Example: 

  • File Name = cgq74p1m.c
  • Time = 11:56:10.995   contains ilogger_w_exportmain from Export.pbl
  • Time = 11:56:12.418   contains n_constructorparmlist  from Tiny.pbl

So I need to monitor for different <FileName, CreationTime> combo to decide whether .C file represents same or different class. This is definitely more complex than I expected.

Alternative is to compile only one PB library at a time but for a 200 PBL app that is no fun. Even for 4 PBL app this restriction is tedious.

If no easier way exists I may just finish my little .NET app and share it under creative commons license so everyone can enjoy.

 

Any hints greatly appreciated. /Michael

Comment
Brad Mettee
  1. Brad Mettee
  2. Friday, 13 March 2020 14:50 PM UTC
Yes, the full link step will fail, but all of the .C files will still be intact after the build. If you're only interested in the source code, this should be all you need, true?

  1. Helpful
Chris Pollach @Appeon
  1. Chris Pollach @Appeon
  2. Friday, 13 March 2020 15:33 PM UTC
Hi Michael;

Here is what I do ...

1) Direct all C++ files to a specific folder ...

In your PB.INI's [PB] section, add the following ...

for example, mine is: CODEGENTEMP=G:\PB2019\CplusPlus

2) Mark the folder G:\PB2019\CplusPlus .... "Read/Write" only

3) Run your M-Code compile (deploy)

4) Now pick up all your C++ source for a given App in the "G:\PB2019\CplusPlus " folder

Tip1: My "G" drive is an SSD HD and I have excluded that folder in my Windows Defender AV for "awesome" compile performance.

Tip2: I do the same as Tip#1 for PowerServer Toolkit deployments as well. ;-)

HTH ... Chris
  1. Helpful
There are no comments made yet.
Roland Smith
Roland Smith Accepted Answer Pending Moderation
  1. Thursday, 12 March 2020 17:53 PM UTC
  2. PowerBuilder
  3. # 3

Main reason that a p-code deployment is so much faster is that it just copies the compiled code that is already in the PBL.

Comment
There are no comments made yet.
Brad Mettee
Brad Mettee Accepted Answer Pending Moderation
  1. Thursday, 12 March 2020 13:14 PM UTC
  2. PowerBuilder
  3. # 4

Have you thought about revoking delete rights on the temporary directory (for the compiling user, or just everyone)? That way you can let PB append to the files, but not get rid of them. Once compile is complete, you'll have a full set of source code waiting to be copied.

I typically use an NTFS RAM drive for compiles, and changing directory rights isn't an issue since they'll be recreated properly next time I reboot.

HTH

Comment
Miguel Leeuwe
  1. Miguel Leeuwe
  2. Thursday, 12 March 2020 13:18 PM UTC
Interesting speed-up !
  1. Helpful
Michael Kramer
  1. Michael Kramer
  2. Thursday, 12 March 2020 14:21 PM UTC
Thx, Brad. Nice tip. My initial thought was compiler will fail when no delete access. So I hadn't modified directory rights.
  1. Helpful
Brad Mettee
  1. Brad Mettee
  2. Thursday, 12 March 2020 14:34 PM UTC
We keep all of our source code on network drives (easier to backup). Compiling from network takes 15 minutes or so. Compiling from RAM drive takes about 2-3 mins. Unfortunately, compiling to M-code still takes over 1.5hrs, even using a RAM Disk, so we're not using that (unless it's for runtime speed tests).
  1. Helpful
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.