Feedback: scope of usage? any problems?

[Romiras]

I started this topic in order to find out that scope of compiler's usage so
that can be improved in the future.

Scope of usage:

• for academic use or just trying to learn possibilities of alternative tool;
• for solving one-time, specific, task;
• having "portfolio" of successfully solved tasks by this compiler;
• want to migrate from another tool because of some features of this compiler;
• a companion tool to another chain of tools
• another case? Please, describe it if possible.

Which kind of problem you encountered that prevents the use to the full extent
of its power?

Order the list of features by its importance to you:

• debugging facilities;
• stability of compiler;
• extending of framework;
• support for compiling source code in ODC documents;
• compiler as plug-in for some popular IDE/editor tool;
• support of XYZ platform;
• set of tools for automation of development process;
• additional tools, like profiler, code analyzer, code browser;
• providing an Oberon-like GUI environment as close as possible (like BlackBox with text as interface);
• automatical resolution of module dependencies by linker;
• independent run-time environment for running modules (e.g. common base for deploying programs), like Java/.NET;

[Frank Hrebabetzky]

I am back after som time in which I continued development of my hobby projects
using the BlackBox Component Builder running under Linux (Ubuntu) / Wine. From
this you can see my main motivation for your tool: Using Linux in future (if I
understood well, cpdev cannot generate Linux executables yet).

Something I got aware only now is that the the BlackBox symbol and code files
are platform independent, so I would need cpdev only to compile the final
libraries and executables which is a relatively small part of an overall
project.

The detailed answers to your questions follow.

Scope of usage

*for academic use or just trying to learn possibilities of alternative tool;

• at home for hobby projects, eventually using the results at work
  *for solving one-time, specific, task;

• will use ComponentPascal for all future hobby projects, using the Component builder so far
  * having "portfolio" of successfully solved tasks by this compiler;

• I am building a base of generic libraries in parallel
  * want to migrate from another tool because of some features of this
  compiler;

• I allways liked specific and separate tools, e.g.: for C programs I use (MinGW) gcc, gdb, emacs

• working in a Linux environment

• create binaries for Linux
  * a companion tool to another chain of tools

• only if necessary (I would prefer to use one compiler only)
  * another case? Please, describe it if possible.

Which kind of problem you encountered that prevents the use to the full extent of its power?
- At first, I was only disappointed that something as simple as "Hello world" didn't work (about half a year ago). Only when I tried to do generate console output with BlackBox I realized how complex that is. Meanwhile I use open libraries (Glib) as much as possible.
- When I tried cpdev yesterday again, I ran into the "no Kernel" error. I saw that it was discussed here, but didn't apply your suggestions yet.
- It is still not clear to me how to work efficiently with cpdev, how to "install it". In my trials I had to copy my project files into the cpdev directory.

Order the list of features by its importance to you:

Important

• stability of compiler;
• support of XYZ platform; (Linux)
• debugging facilities;

• additional tools, like profiler, code analyzer, code browser;
  (- an analyzer which indicates dead code or unused variables might be
  interesting

• profiler: interesting, with very low priority;

• code browser: I am happy with emacs, the Modula mode works reasonably well with Oberon programs )
• automatical resolution of module dependencies by linker; (a commodity, not very important)

Not important

• extending of framework; (no more more libraries and tools, use the huge wealth of existing ones)
• support for compiling source code in ODC documents; (I prefer the universally understood plain text)
• compiler as plug-in for some popular IDE/editor tool;
• set of tools for automation of development process; (use existing tools instead, such as make or shell scripts)
• providing an Oberon-like GUI environment as close as possible (like BlackBox with text as interface);
• independent run-time environment for running modules (e.g. common base for deploying programs), like Java/.NET;
  (no, keep it simple and small instead)

[Frank Hrebabetzky]

I forgot one feature which would be interesting: Conditioned compilation
(pragmas). This way, the same program code could be used for Windows and
Linux, which might require different library imports and references.