COMPILE-SYSTEM, AGAIN

[Scott McKay <SWM@sapsucker.scrc.symbolics.com>]

    Date: 10 Jul 1988 22:02-EDT
    From: NCRAMER@G.BBN.COM

    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: royt@pravda.gatech.edu (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
    systems.

    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.