[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Date: 10 Jul 1988 22:02-EDT
Date: Fri, 8 Jul 88 15:48 EDT
> From: Scott McKay <SWM@sapsucker.scrc.symbolics.com>
> Subject: question about compile-system
> Date: Fri, 8 Jul 88 13:42:09 EDT
> From: email@example.com (Roy M Turner)
> I have a system that has several component systems, but even when I do:
> compile system Medic :include-components yes
> it blithely *loads* the component systems rather than compiling them--even
> when there have been changes that would cause compilations if I compiled each
> of the component systems separately....
> I believed when I designed SCT, and still believe now, that it would be
> a gross violation of any reasonable model of modularity for :Compile
> System to cause any component systems to be compiled. Consider a
> component system which is used by a number of systems, but none of the
> developers of those systems actually maintain the component: they just
> use it. .... The maintainer of that component
> system, and the other users, would have every right to be annoyed with
> you for recompiling it when you recompiled your system.
> Therefore, :Compile System only loads its component systems. In order
> to compile components, you must do them explicitly. If your component
> systems are truly just part and parcel of the main system, and have no
> utility as stand-alone systems, then you could use defsubsystem....
The problem here is that once again SCT/Defsystem is capable of _any_ and
_everything_ in the universe. Except that it is often difficult, if not
impossible to do the simple, straight-ahead things that most users expect
(and want) it to do.
Such as? (I happen to agree with you: for some things in SCT, this is
surely true, but I would like to know what you think.)
My case is between the two extremes above. I'm in the middle of the
development of a number of projects that all use a central, core system.
The core system is not standalone; it is common to several systems; and
its on-going development is coincident with the development of the systems
that use so it is constantly changing and its maintainer (me) is either
the same as or works closely with the maintainers of the top-level
Any change in the core system needs to be propagated to the top-level
systems. I can't use DEFSUBSYSTEM, because (at least according to the
documentation) it doesn't maintain its own journals -- from which I infer
that any change in the core system would result in multiple bin files
being created as each top-level system checks its own journal and
recompiles the changed file. Instead (rather than hacking DEFSYSTEM) I
have my own set of hacks that depend on doing an explicit and cumbersome
COMPILE-SYSTEMs on all the [logical-]component systems.
I have a design for something I call "aggregate systems" which will
manage this automatically, but there have been more important things to
do, so I have never had the time to implement it.
[All this is relevant only during development, of course; presumably as
each system is shipped, it will have its own, new, tidy system definition,
which will incorporate the component systems.]
In this given case, the work around is not that hard or painful. However,
in the general case I suppose the right answer would be for DEFSYSTEM or
COMPILE-SYSTEM to have a switch. I would argue that the correct default
is to _do_ the compile, but I would be happy just with the toggle.
I think you should continue what you are doing now, even though it is
cumbersome. I also strongly believe that the correct behavior is for
SCT to do what it does now.