<div>The class name BaselineaofMagicMouse is constructed from #baseline: ‘MagicMouse’ and furthermore a project by that name is expected. This is what I meant by auto-constructed.</div><div><br></div><div>I have recently been able to #ensureLatestMetacello, but I still cannot load MagicMouse. *shrugs*</div><div><br></div><div>I would wish Monticello would have a Baseline object/class in the preamble of a Monticello packagetodescribe load steps to get all dependencies👁 Then it would have more of a build role. I do realize my mvm file is an artifact also separate from the packages but I can name it what I want and pull packages.</div><div><br></div><div>I will take another look at Metacello. What would a Baseline for all of Crypto look like 👀?</div><div><caret></caret><br></div><div id="protonmail_signature_block" class="protonmail_signature_block"><div><div>Kindly,<br>Robert<br></div></div></div>  <div><br></div><div><br></div>On Sun, Jun 7, 2020 at 17:52, Jakob Reschke <<a href="mailto:forums.jakob@resfarm.de" class="">forums.jakob@resfarm.de</a>> wrote:<blockquote class="protonmail_quote" type="cite">  Hi Robert,<br><br>Have you tried Metacello recently? The BaselineOf subclass for a<br>project is very much like the POM in a Maven project or a Gradle file<br>(whose presence is also required for these kinds of projects). The<br>Metacello baseline declares which packages belong to this project, and<br>the dependencies and where they are coming from. It is not<br>"auto-constructed" as you put it, you write this specification<br>yourself. And it is declarative, just like Maven or Gradle files<br>(well, the latter can be turned into imperative style as well AFAIK).<br>I don't know what is not "first-class" about it as a<br>bill-of-materials. Put the BaselineOf subclass of the project in a git<br>repository and you are all set -- in a Git repository you don't even<br>need the ConfigurationOf part (because a commit usually is exactly one<br>configuration of your project). The baseline can also declare<br>conditional loading, to load different parts for different Smalltalk<br>vendors (Squeak, Pharo, ...).<br><br>Metacello has most of the features you asked for, except controlling<br>external tools (gcc, etc.). But you should rather use external tools<br>for that (like CMake, Gradle, ...). You can call them from Squeak via<br>OSProcess if you like. Metacello is not really a build system because<br>since when have we needed "builds" in a running Smalltalk environment?<br>It is rather a package manager, like apt. SmalltalkCI [1] is somewhat<br>of a build system, and it uses Metacello to load packages and their<br>dependencies into fresh images, in the usual setups.<br><br>Why reinvent the wheel?<br><br>What's missing in comparison to the Maven/Gradle world is one or more<br>central repositories to discover Metacello configurations/baselines,<br>so you could omit the Internet locations of dependencies in your own<br>projects. But you wouldn't automatically get that with extended<br>Monticello configurations either. For the older Metacello there is<br>something like this on SqueakSource already, but since it is<br>Monticello-based, it is not so appealing for Git-oriented projects,<br>and consequently Pharo.<br><br>I suggest you try Metacello, it is not so bad [2][3]. Its own code is<br>hard to follow, but not the descriptions you write for your own<br>projects.<br><br>[1] https://github.com/hpi-swa/smalltalkCI<br>[2] http://pharobooks.gforge.inria.fr/PharoByExampleTwo-Eng/latest/Metacello.pdf<br>(applies to Squeak equally well)<br>[3] https://github.com/Metacello/metacello/blob/master/docs/GettingStartedWithGitHub.md#create-baseline<br><br>Kind regards,<br>Jakob<br><br>Am So., 7. Juni 2020 um 20:24 Uhr schrieb Robert Withers via<br>Squeak-dev <squeak-dev@lists.squeakfoundation.org>:<br>><br>><br>> On 6/7/20 2:17 PM, Robert Withers wrote:<br>> > I am not sure I can express myself effectively, as I don't just want to<br>> > say yuck and carry on. I owe an explanation of my opinion. I strongly<br>> > dislike the auto-construction of #baselineOf and #configurationOf<br>> > methods and their required presence.<br>><br>> > We should have repositories of<br>> > artifacts, like maven repos, and dependency specification in a build declaration script.<br>> > Call it a .sqm for Smalltalk Qualification Module. This has the protocol<br>> > of the new Smalltalk-based Gradle.<br>><br>> Each projects .sqm file is in the git root directory for that project,<br>> exactly as the POM is for Maven. Andso, it si under git control. As the<br>> POM is specified as the fundamental unit of work, so the SQM file for<br>> Straddle.<br>><br>> Straddle is the Smalltalk analog to Gradle, which helps teams build,<br>> automate and deliver better software, faster. From the inside of an<br>> image. Browse Straddle config file (SQM).<br>><br>> Just wanted to clarify a little bit.<br>><br>> K, rabbit<br>><br>> ><br>> > Kindly,<br>> > Rabbit<br>> ><br>> > [1] Gradle - https://gradle.org/<br>> ><br>> >> Dave<br>><br>><br></blockquote><div><br></div><div><br></div>