[Vm-dev] tty's hypothesis on configH in CMakeVMMaker

Tue Jun 17 01:15:31 UTC 2014

On Mon, Jun 16, 2014 at 5:16 PM, Igor Stasenko <siguctua at gmail.com> wrote:

On 17 June 2014 01:49, Eliot Miranda <eliot.miranda at gmail.com> wrote:

On Mon, Jun 16, 2014 at 4:38 PM, Igor Stasenko <siguctua at gmail.com> wrote:

On 16 June 2014 18:31, Eliot Miranda <eliot.miranda at gmail.com> wrote:

On Mon, Jun 16, 2014 at 3:33 AM, Igor Stasenko <siguctua at gmail.com> wrote:

Yes, config.h is a leftover of old make process which i had to port over to
cmake build process without need to do big changes in source code.

I am strong opponent of idea that configuration variables shall
automatically , dynamically and implicitly change depending on where you
compiling the code. Configuration , as a whole can change, but not its
variables.

They must be defined once and stay same regardless of building environment.

That gives you a better chances that software which you successfully built
using same configuration will work identically no matter who or where is
built it.

And sure thing, for having variations, you can define own configuration
e.g. MyVMWith(orWithout)UUID

and use it to compile VM with that flag changed.

But as i say, key here that this flag is set by your hand once and forever,
not by some pre-build configure script which depends on where it runs on.

Depends what you're talking about.  In this case some linuxes have
/usr/include/uuid.h and a program called uuidgen, others have
/usr/include/uuid/uuid.h and a program called uuidgenerate (let alone other
unixes).  IMO it is not the business of a VM source generation pass to
decide this.  It is a compile-time configuration pass.

My take on it goes from following:

you make two configuration - one which uses

/usr/include/uuid/uuid.h

another which uses

/usr/include/uuid.h

that way leads to generating the VM immediately before one builds, and
that's a very bad direction because it goes against any repeatable build
process that records the C source, that allows debugging older VMs etc.  I
disagree.

Straightly opposite. it guarantees that it will generate exactly same
artifact (and sources) for same configuration. No matter how broken your
build system is.

No it doesn't.  The resulting artifact depends on compiler, linker and
libraries and these can change.  The VM configuration step can't control
the entire platform.  It's a waste of effort making it try.  But let's
agree to disagree.  Timothy is producing a CMake system that the Squeak VM
team is happy with.  Hence we'll ask Timothy to /not/ have configH produced
by the VM.

When I was VM lead for VW I also maintained a system that didn't use
automake.  It just used makefiles and the flags there-in were maintained
manually.  But that was a different situation.  The company supported
specific OS versions.  But I think the Squeak/Pharo VM on unix is
different.  THis is open source and we should make it as easy as possible
for people to get the software running on their machine (hence a repository
containing ready-to-build C source rather than pointing them at an image
and VMMaker).  I say this to point out that I've changed my mind on this
issue.  That I'm backing the configure-at-build-time approach for a reason.
 But I accept we disagree.  Cheers!

Because when it broken - it will simply fail & report.. instead of trying
to hide problem among numerous ifdefs which you then discover only hours
(if not days) after, when some client tries to run things on his machine
(which apparently will have completely different environment than on
machine where you built the thing).

The build fails and reports too.  It doesn't fail silently. It may take
platform knowledge to decipher the failure message but its there,
especially if the build is careful enough to record a log file.  That's
what we get with Jenkins too.

and when you building VM you always know which one you build and which one
works...

in contrast to situation when you have like 50+ automagically resolved
flags &  dependencies, so you don't even know what module is included into
final artifact without checking it by hand.

No, its not magic.  Its autoconf/CMake.  There's good reason to expect the
maintainers of autoconf and CMake to do a better job detecting and deciding
on the right platform make files for a given unix than the Pharo/Squeak
community.  i.e. thousands of unix programs, many of them critical
infrastructure such as apache were built using autoconf and are buult using
CMake.  Your approach complicates the lives of people trying to port to
unusual unix platforms such as Open Solaris, FreeBSD etc.  I don't see the
point of forcing people through the VM generation step just to manually do
a configuration their platform tools will do for them.

No, it is magic, because when it fails, especially at linking stage, you
often have no clue why the heck symbol X is undefined and who the hell
defines it and where (because you simply cannot know names of all functions
of all modules VM and its plugins using)..

Yes I can.  It's called "nm".

and next you do is use command line tools , like find , (which i always
forget how to use  - probably because it is very intuitive to use ;) in
order to find in a system, is there any source file/header that defines
this symbol which you omitted or messed up with ifdefs/defines & makefiles
configurations.

How do you determine the configuration in the first place but by engaging
with the platform?  And find is hard to use??

Look, all thats happening with your approach is you're freezing something
which worked once you solved all the platform problems.  That didn't stop
you having to solve the problems up front.  t just meant that once you had
something that worked you could record it.  But a platform expert can make
the configure-at-build-time scheme work on arbitrary configurations, unless
you shackle them to a specific configuration.  Anyway... enough.

But what can be worse is that sometimes that missing symbol belongs to
library which is [not yet] installed on your system (or installed but wrong
version, or it is 64-bit while you want 32-bit), since you trying to build
on a fresh machine.. and so your search extends to world-wide-web..
(because nobody told & written that you need to install these deps before
building it and where to get them) because all knowledge about critical
dependencies is hidden in 1M configure/ac scripts + ifdefs, of course,
which no human can comprehend... and  so time spent on making things work
increases in geometrical progression (because again where the guarantees
that you will install correct version of library & that library in own turn
won't have dependencies which will force you to enter nested
search/install/configure/build loop?)

Now if you have configuration, which says:

 - this works with that, that and that, and here's how to prepare your
system before building it. For other systems it may not work, so try at own
risk.

This is at least FAIR and straightforward.

Because when i want to build VM which includes/uses feature X, it should
include X, not X' or Y, (or even worse - automatically ignore it because
it's not avail on your system).

Because if feature cannot be strictly guaranteed, i prefer to see the build
process to simply abort reporting failure.. instead of behave fuzzily & be
smart and nicely trying to guess best possible combination of bells &
whistles to build on current platform.. it is wrong place for being smart.

The approach of having lots of configurations determined at VM source
generation time leads to VM source which becomes obsolete, is inflexible,
is duplicated.  There needs to be a sensible split.  VM generation time is
not the time to choose things like sets of plugins, particular include file
locations.  IMO it should only produce a full suite of source.  A build
directory is the place to decide what plugins to choose etc, allowing
special configurations for special uses (an embedded device vs a desktop
OS, etc).  Compile time configuration is the time to choose include files,
library names etc, etc.

does it really matters at which point you decide how to configure build?

Yes.

what matters that you will always would want to configure it.. and you
always would want to spend as little as possible time on it.. and having
things easy and convenient to configure or modify.

And what can be better place to configure things than smalltalk
environment? :)

Seriously?  You think Sueak/Pharo is better connected to unix platform
libraries than autoconf/CMake?  We can't even do symlinks properly yet.

Abstraction layer... This is what it gives to you so you don't have to deal
with auto/symlinks etc by yourself..

Perusing classes & methods, or perusing files in numerous (sub)directories
+ requiring knowledge of makefile & autoconf DSLs.. which are worst
nightmare? For me the choice was obvious..

yes, you still cannot avoid some perusing.

that is inevitable part of process, but at least you can choose where (not)
to do it.

On 15 June 2014 23:27, gettimothy <gettimothy at zoho.com> wrote:

Hi Eliot.

I have a theory on the Pharo CMakeVMaker configH method.

CogUnixConfig configH

" right now its like that "

^ '

#ifndef __sq_config_h

#define __sq_config_h

/* explicit image width */

#define HAVE_INTERP_H 1

....

based on my work getting the
oscogvm/platforms/unix/plugins/UUIDPlugin/sqUnixUUID.c... to compile.

Working from the C source up to configuration then to Squeak....we start
with the source code for sqUnixUUID.c

#include "config.h"

#if defined(HAVE_SYS_UUID_H)

# include <sys/types.h>

# include <sys/uuid.h>

#elif defined(HAVE_UUID_UUID_H)

# include <uuid/uuid.h>

#elif defined(HAVE_UUID_H)

# include <uuid.h>

#else

# error cannot find a uuid.h to include

#endif

On my platform, I needed that HAVE_UUID_H define set.

To do that, I modified the acinclude.m4 file to check for the <uuid.h> (my
changes in Bold--I emailed you this previously)

AC_MSG_CHECKING([for UUID support uuid/uuid.h] and uuid_generate)

AC_TRY_COMPILE([#include <uuid/uuid.h>],[uuid_generate;],[

AC_MSG_RESULT(yes)

AC_CHECK_LIB(uuid, uuid_generate, LIB_UUID="-luuid")],[

AC_MSG_RESULT(no)

*AC_MSG_CHECKING([for UUID support uuid and uuidgen] )*

*AC_TRY_COMPILE([#include <uuid.h>],[uuidgen;],[*

*AC_MSG_RESULT(yes)*

*AC_CHECK_LIB(uuid, uuidgen, LIB_UUID="-luuid" )],[*

*AC_MSG_RESULT(no)*

*AC_PLUGIN_DISABLE*

*])*

])

AC_SUBST(LIB_UUID)

For the source code to see it, the config.h file needs to be in place with
that HAVE_UUID_H  flag*, so in Squeak, I over-ride the configH method to
include that define flag:

configH

^ '

*#define HAVE_UUID_H 1 *

*#define HAVE_UUIDGEN 1*

#ifndef __sq_config_h

The CMakeVMMakerSqueak 'generate' message to a builder dumps that config.h
to the build directory.

running the build.sh generated script invokes

cmake .

 command which looks in the specified source/config directory to configure
the GNU-Makefile to look for that source code and pairs it with the
generated config.h

The CMake generate GNU-Make system then uses those source/build artifacts
to put the output in the oscogvm/products directory.

So, let me summarize.

1. We know that the plugins depend on config.h

2. Ideally, that config.h should be incrementally build by the Squeak
plugins themselves or the CMakeVMMaker configurations. How? I don't know
yet. Looking at it, the UUIDPlugin class would have to contribute its
configuration information.

    this is non-trivial.

3. So, in the meantime, CMakeVMMakerSqueak configurations are classes that
encapsulate a <drum roll please> Configuration.

4. It seems reasonable to make this part of the configuration setup process.

5. I will/have documented in in the HelpBrowser HelpTopic for the system.

My apologies for the long-winded explanation.

HTH.

tty

*I just noticed the sys/uuid in the sqUnixUUID.c code, that implies a
further nesting in the .m4 file Let me know if you want me to write it for
you.

-- 

Best regards,

Igor Stasenko.

-- 

best,

Eliot

-- 

Best regards,

Igor Stasenko.

-- 

best,

Eliot

-- 

Best regards,

Igor Stasenko.

-- 

best,

Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140616/72ef7e0b/attachment-0001.htm