[Vm-dev] reorganizing opensmalltalk-vm

Ben Coman btc at openinworld.com
Sat Oct 27 02:59:10 UTC 2018


On Sat, 27 Oct 2018 at 04:03, Jakob Reschke <forums.jakob at resfarm.de> wrote:

>
> On the topic of the directory structure, I would prefer option 1 and
> keeping the "generated" name in favor of "gensrc". Spelling it out makes it
> clearer, IMHO. I also prefer third-party over othersrc because the latter
> is too generic.
>

"othersrc" was a workaround since having both "/src/third-party" for
our-source specifying which versions of third-party libraries are used
and also top-level "/third-party" holding not-our-sources felt odd to me.

Possible alternatives "/src/third-party-specs"
"/src/third-party-versiosn"  "/src/versions"   "/src/specs"

Rethinking "/cachedsrc", maybe better as "/third-party/buildcache" for
libraries dynamically downloaded by build.
(but I'm ignorant of where the build currently does such caching and that
may just be fine as it is)


By the way, once the "real" source code is in the repo, and the generated C
> source code is as well, the generated sources will [lag] behind the
> Smalltalk sources most of the time, won't they? That might be confusing for
> people who come to the repo, clone or download it and just want to compile
> the VM. "Hey I pulled commit abc that fixes xyz, yet I still have the bug
> when I build it!?" Are there any plans to tackle this?
>

I'd expect the local `make` to ensure the generated sources match the
smalltalk sources which are all then committed together after local testing.
Although considering how Pharo currently works with git, the Smalltalk
sources are only written to disk during a commit,
so yes at that moment the generated sources lag the Smalltalk sources.
Perhaps when `make` notices stale generated-sources and regenerates them it
also could do a `git commit --amend`
to ensure both are in-sync within each commit for when that is later pushed
to server.

cheers -ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20181027/b0647e40/attachment.html>


More information about the Vm-dev mailing list