[Vm-dev] [OpenSmalltalk/opensmalltalk-vm] Note on runtime/tcl-8/tcl-openssl which provides tls.h (8f71c4a)

[Eliot Miranda]

Hi Subbu, Hi Tobias,

> On May 2, 2020, at 6:36 AM, K K Subbu <kksubbu.ml at gmail.com> wrote:
> 
> On 01/05/20 8:16 pm, Tobias Pape wrote:
>> I really want to avoid to have user-configural options being
>> necessary for a default install.
>> ./configure should be sufficient to get a working VM regardless of
>> operating system.
>> If that is not the case, we got to change the configure-mechanics.
> 
> +1. ./configure serves two purposes - detecting host/toolchain/library configurations on the fly and handling feature specific variable settings for a build Makefile. We also have separate files like plugins.int, plugins.ext etc that go into this Makefile.
> 
> It would be better if the second purpose (i.e. feature vars) is consolidated into a conf file containing simple name=value pairs. Such a file is much easier to generate or edit from Squeak or platform tools. A build Makefile can pick up all variable settings from such files. We won't need separate files like plugins.int, plugins.ext etc.

We need to tease things apart a little further.

configure does (at least) these things 
- detects platform information (word sizes, include files and their contents, presence or absence of additional libraries)
- checks if chosen tool chain can compile and link an executable program

hand-crafted code takes configure output and plugins.int/.ext to produce very poor makefiles that font even maintain dependency information (so that code is not recompiled when included files are modified, a serious deficiency)

plugins.int/plugins.ext & branding files (mvm script in configure builds, too-level Makefiles in Windows & MacOS builds) specify bane and contents of a VM bundle

Note that this last tailoring step is essential; different users want to be able to build specific VMs with specific contents.  Those specific contents don’t depend on configure, they depend on the builder’s requirements.


So no, we do /not/ want to conflate configuring a build and determining what is available on a specific platform.

It does make sense to use configure to derive platform-specific information.  But as I’m tired of trying to explain, this needs to be done only once per platform, not once for every build on a platform.  For example, a structure which generated a configure.h in 
      build.FooSizeProc/include/configure.h
would be a huge improvement (for those that have to do lots of vm builds in their development) over the per-build Linux mess.

But it does not make sense to, for example, not build any doubt d plugins because the current platform is missing libraries that should have been installed. It makes sense not to build sound plugins on platforms that don’t support sound.  On platforms where sound is supported what we’d like is for the build system to complain that sound cant be built rather than silently not building sound plugins.

As far as the dependency issue and the hand-crafted code that autogenerates makefiles, it is brittle, opaque, has a phase problem (one has to run a compile step then a configure step before changes propagate to the actual build), and deficient (ni dependency information). Makefiles written as per Windows and MacOS aren’t subject to these flaws.

> 
> Regards .. Subbu