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

[Igor Stasenko]

On 17 June 2014 04:14, David T. Lewis <lewis at mail.msen.com> wrote:

>
> On Mon, Jun 16, 2014 at 09:31:13AM -0700, Eliot Miranda 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.
> >
> > 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.
> >
>
> Philosophical points of view aside, I have the uncomfortable feeling that
> some (all?) of the people in this discussion may have never bothered to
> look
> at how Ian's CMake build actually works.
>
>
the fun thing is that i looked at Ian's work, and drawn inspiration from it
which leaded to creating CMakeVMMaker. Presence of Ian's work is direct
reason why i chosen to use cmake for automating vm build system.. and
created CMakeVMMaker..
I just did one more logical step: generate cmake files on the fly from
smalltalk instead of manually editing files.

To put it simply: It implements the approach that Eliot is trying to
> advocate.
> And it works.
>
> My own personal opinion: Philosophically, I tend to favor Igor's point of
> view
> (put things in the image as much as possible). But in practice, this is a
> case
> where the implementors of CMake are in a better position to deal with
> platform
> differences than we (the Squeak/Pharo community) can afford to do.
>
>
building VM is not responsibility of cmake implementors.
And of course, you can use whatever cmake provides.. just keep that
knowledge in image, not in files.


> Furthermore, the organization that Ian created puts the responsibilities
> where they belong, with minor customizations for the various plugins and
> modules located in their respective platform source directories where
> needed,
> and overall control of the CMake configuration and build located in a small
> set of CMake files.
>
> To speak plainly, I have a hard time understanding why something that is
> well
> designed and implemented by its original author needs to be reengineered
> and
> reimplemented by every new person with a new opinion. Why not just support
> and
> contribute to the original author? What's so difficult about that?
>
>
At the time i started, there was no CMake configs adopted to work to build
Cog VM.

And in general, there is a rule of thumb:
 - you can use command line scripts to script & automate whatever you gonna
need, until first IF statement in it. At that point you should consider
using normal programming language instead of shell scripts etc.
Same applies to CMake, Makefiles etc..

Because logic is a knowledge about system, and it must be well written and
easy accessible.. for maintainers. Because logic tends to change over time
or you may need to add new etc.



> Dave
>
>

-- 
Best regards,
Igor Stasenko.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140618/45067a42/attachment.htm