FWD » Core Development » Conversion Tools

Multiple customers have noted that using the FWD conversion tools on an existing 4GL project is quite messy because:

• We assume the 4GL project structure must live inside our conversion project structure.
• We emit intermediate artifacts throughout the project structure and distressingly (to customers), alongside the original 4GL source code/schemata.

As customers move to develop 4GL code and test/debug/deploy in FWD, we need to make it much easier to do. One of the first steps is to eliminate the pain caused by our messiness. Plan:

1. Artifacts that are shared project-wide should be moved into the cvtdb. For example, the registry.xml and name_map.xml should be in the database instead of as .xml in the file system.
2. All per-source or per-schema file artifacts (e.g. .cache, .ast, .jast, .schema, .dict, .p2o...) should be emitted into a conversion artifact directory. This would be a configurable location which has a directory tree that mirrors the input structure of the project. In other words, if we are processing abl/myapplication/some/path/prog.p, then we would store related artifacts in <conversion_artifact_directory>/myapplication/some/path/prog.p.*.
3. Some conversion artifacts can be dropped by default. I'm thinking about the .parser and .lexer files here. They are of limited value in most circumstances and we can always enable them in an environment in the rare case they are needed. This will save some disk space in the common scenario. If these do get enabled, they should be emitted into the new conversion artifact directory.

Eventually, even the file-level artifacts will be in the database but for now I don't want to complicate the solution for this task.