Hi David,
>>> David PONCE <david.ponce@...> seems to think that:
[ ... ]
>I thought a little more on that change, and I wonder if it would be
>worth setting the `commands' slot with an instance of an
>`ede-compilation-commands' class that would handle the production of
>compiler commands via generic methods. For example we could have:
>
>`make-form'
> A method that will return a string with commands for use in a
> Makefile rule.
>
>We could also imagine other production methods like:
>
>`shell-form'
> That will return a string with commands as a shell script.
>
>Or:
>
>`lisp-form'
> Which will return a string with commands as Lisp expressions.
>
>etc..
>
>We could have an `ede-compilation-commands-basic' class that will use
>a list of strings and method symbols (like now) as source.
>
>Later we could propose a more elaborate
>`ede-compilation-commands-tempo' class which use tempo templates to
>represent a command stream.
[ ... ]
I will start by trying to a explain a little about the compiler/linker
objects. My memory on this topic is a little rusty though. :(
Some targets, like those for C code, can have many different
compiler/linker combinations on a given system, such as using gcc, cc,
Acc, pascal, fortran, or whatever.
It is important for someone to be able to create new *instances* of
these objects so new compilers can be added via custom without
knowing Emacs Lisp. Thus, much of the customization is plain strings.
When building new compilers, it is important to be able to clone with
inheritance. This is handled by having those classes use
eieio-instance-inheritor as a base class. This is important so that
you can change one field of a given compiler without modifying the
original, and so that you can change the original and have that
change captured in all objects that use that compiler, or derivations
of that compiler.
Phew! Anyway, some targets types need specialized subclasses of a
compiler representation, so class inheritance is used for those.
Doing so improves flexibility at the expense of possible confusion
should a use try to add new types of compilers.
This is what makes your proposition both interesting, and difficult.
Getting a generic feature into the compiler object to allow small
changes to the text of the provided shell commands without custom
methods on the compiler could be very useful! I learned many
interesting features of make so I could avoid the need for that
feature.
Having a separate slot (or field in Java speak) for commands that is
mutually exclusive to the existing slot for the output commands (as
strings) could confuse someone trying to use the system w/out
programming in lisp. If a given solution sets the :make-form slot,
then a use may try to modify the existing :commands slot and not
understand what has happened.
I think your earlier solution suggested a different :type of value
for the :commands would solve the problem, but makes it very
difficult to clone and tweak the commands.
It may be appropriate to have the :commands slot have a :type that
represents a tempo template, or a skeleton. Any of the built-in
template representations could be good. Special variables could be
set during template expansion to simplify the customization of the
slots to extract names of different variables that are created by the
slot.
Anyway, the core classes are in ede-proj-comp.el. The Commentary
section attempts to also explain the above. I find the
ede-compilation-program and others to be a little confusing. I had
developed a lot of EDE before realizing that they were pretty well
required. (Paul K. made this pretty clear describing his JDEE
compilation scheme.) It took a couple re-writes of a dynamic
compiler representation to get something that worked well.
Did that make any sense?
Eric
--
Eric Ludlam: zappo@..., eric@...
Home: http://www.ludlam.net Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net GNU: http://www.gnu.org
|