[Vm-dev] Naming convetions for Cog unix builds question (abldt, bldt, dbldt, astbldt, asbld etc)

[Eliot Miranda]

Hi Timothy,


On Wed, May 28, 2014 at 8:15 AM, gettimothy <gettimothy at zoho.com> wrote:

>
> Hi Eliot,
>
> I have condensed your email into somewhat of a bullet points version. I do
> have one concern and that is newbie-end-user ease of use.
> *I list my concerns and comments in italics* among your points.
>
>
>
>  There are three VM configurations.
> Assert configurations include assert code with -01 optimization
> Debug configurations include assert code with no optimization.
> Production has asserts removed by the preprocessor.
>
> a and ast are prefixes for assert.
> d and dbg are prefixes for debug.
> t suffix is for "threaded" and means that these VMs have the threaded
> heartbeat, with the others using the problematic itimer heartbeat.
> mt stands for multi-threaded, the experimental non-blocking FFI VM.
>
> You much prefer a top level build.OS/WordSize/Processor directory with a
> HowToBuild file that handles make, make debug and make assert builds.
>
> build.win32x86
> build.macosx32x86
> build.linux32x86
>
>
>
>
> *Sounds good. I propose a build.linux32x86_64 to handle the special case
> of building agianst 32 bit compat libs on debian/slackware.  Yes, it can be
> done in the x86 directory, but consider the newbie end user who wants to
> get up and running hacking vm's quickly.*
>

Yes I like this.


>
>
>
>
>
> *I also propose a parallel cmake_build.OS/WordSizeProcessor tree to
> minimize confusion and traps while we get our heads around and learn the
> idiosyncracies of
> CMake.cmake_build.win32x86cmake_build.macosx32x86cmake_build.linux32x86cmake_build.linux32x86_64*
>

Sounds good.


>
> *I will also re-name the CMakeVMMakerSqueak XYZConf classes to
> SqueakBuildWin32x86Conf SqueakBuildMacOsX32x86Conf etc so there is a
> one-to-one corresponsdence between thedefault configuration and its
> directory. (Customizations can be subclassed off of these defaults and
> routed whereever by the developer if needed)*
>
>
>  If CMake makes it possible and convenient to create the three "pad"
> builds in build.linux32x86 then fine.
> e.g. on mac there's a CoreVM.xcode alongside a CoreMTVM.xcode and they
> create Assert.app AssertMT.app et al
> on cygwin the one makefile cygwinbuild/Makefile creates build buildmt
> builddbg et al.
>
>
>
> *I don't know. The current pharo/squeak structure just specifies where the
> build directory is. *
>
> *Different configurations overwrite what is in the existing directory.*
>
>
> *I Did a quick search, I ran into this:
> http://stackoverflow.com/questions/7724569/debug-vs-release-in-cmake
> <http://stackoverflow.com/questions/7724569/debug-vs-release-in-cmake>So, I
> guess the answer is "yes" but it has not been implemented.I will try.*
>

OK, thanks.

Then in each non-autoconf build directory have a lang/vmarch/mmarch
> directory
> lang is either squeak or newspeak,
> vmarch is either stack, cog or sista, and
> mmarch is either v3 (the current ObjectMemory) or spur. Hence:
> [squeak|newspeak][stack |cog | sista |][v3 | spur] [2!]x[3!]x[2!] = 24
> directories
> squeak.stack.v3
> squeak.stack.spur
> squeak.cog.v3
> squeak.cog.spur
> squeak.sista.v3
> squeak.sista.spur
> newspeak.stack.v3
> newspeak.stack.spur
> newspeak.cog.v3
> newspeak.cog.spur
> newspeak.sista.v3
> newspeak.sista.spur
>
> Then there would be a single HowToBuild in each top-level build dir
> explaining how to build on that platform.
>
>
> Again on win32 under cygwin and on mac os x under xcode it is easy to keep
> the non-mt and mt builds at the same level, sharing a directory.
>
>
> *I am a bit confused here. Are these top-level directories at the same
> level as build.os.wordsize.platform? *
> *i.e:*
>
>
>
> build.linux32x86/
> ...
> squeak.stack.v3
> ...
>
>
>
> *or are they sub-directories of it? i.e*
>
>
>  ...
> build.linux32x86/squeak.stack.v3
> ...
>
>
>
The latter.  Each top-level build directory corresponds to a host
architecture (OS, processor, word size).  Within each top-level build
directory are all the variants of VMs that we can build.  That fills out
the 2d grid of os/processor vs VM variant.

-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140528/72c32a4e/attachment.htm