D
dbeavon
Guest
>> I am trying to understand your requirement better. COMPILE statement looks at a single file with in the context of the PROPATH. Since ABL is both interpreted and compiled, you don't have to compile all the referenced classes to compile a .p. Does this not work for your requirement? I agree that the requirements aren't 100% clear. It sounds like a question related to *production* deployments ... but the technique/strategy of partial compilation sounds like something one would only be attempting in a *development* environment. For *production* purposes, you shouldn't be taking risks, and you should compile "everything" (whatever that may mean in your case). Start things out by clearing the r-code in the PROPATH so you don't have any cruft remaining from a prior build. Does your solution involve one monolithic project with tens of thousands of programs? It might be more manageable to break things up into smaller projects that are managed as deployment units. If you need to deploy a change to a project that is at the top of the dependency stack (for example in U/I -related code only) then you can use your discretion to limit the amount of compilation that is done. Just deploy one of the many projects. A *single* ABL program should NEVER be a deployment unit. That may have worked twenty years ago, but it is a losing strategy these days with so much code re-use and multiple layers of software that depend on each other. >> Depending on the size of your application, the simplest answer may be to compile everything. This is the direction that CI/CD pushes Yes, compile "everything". Compilation is CPU-bound so get a build server machine with plenty of cpu's. Every time you double the CPU cores, you cut the compile time in half. Pushed to the extreme you may run into a Progress bug related to concurrent use of actively-changing r-code files but there is probably a workaround for that if you encounter it (see community.progress.com/.../59721 ).
Continue reading...
Continue reading...