assets/developer-notes/stephanie-gawroriski/2017/10/31.mkd

   1 # 2017/10/31
   2
   3 ## 12:06
   4
   5 I could refactor the project system, but I think I will hold off on that for
   6 now. I will just setup `JITPipe` which later on can be remade as needed to
   7 support a new refactored project system. The project system would keep the
   8 same layout, but it would just be new cleaner classes.
   9
  10 ## 12:18
  11
  12 Okay, forget that I am writing new classes. But I will keep the old code
  13 around until nothing uses it. Basically my idea is `SourceManager`. A later
  14 `BinaryManager` will depend on a `SourceManager` but also have the  means to
  15 add new binary projects and such. Depending on the complexity I want, I can
  16 allow sources to be mutable. If sources are mutable then that would be a bit
  17 more complex. For the most part however, the build system runs, loads the
  18 needed information, then it will stop. But I can have it where new source code
  19 could dynamically be added. For the most part though, every source project
  20 will not have dependencies in any way, they will be completely standalone.
  21 This simplifies things. All the dependency logic will be in `BinaryManager`
  22 for the most part.
  23
  24 ## 12:24
  25
  26 I can however, add support for checking ZIP files to see if they are source
  27 code. But, the main thing is that it would be nice to support building on
  28 limited systems, but that might not be worth it as much. But even then,
  29 there could be a ZIP extractor which handles the limited systems.
  30
  31 ## 12:27
  32
  33 I would say immutable sources would be much cleaner and simpler to write.
  34
  35 ## 12:28
  36
  37 But lazy initialization would be faster though, for the most part.
  38
  39 ## 14:32
  40
  41 This means that the `squirreljme-build-base` project can go away too so that
  42 the build system is for the most part entirely within a single project.