<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 17 June 2014 04:14, David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><br>
On Mon, Jun 16, 2014 at 09:31:13AM -0700, Eliot Miranda wrote:<br>
><br>
> On Mon, Jun 16, 2014 at 3:33 AM, Igor Stasenko <<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>> wrote:<br>
><br>
> ><br>
</div><div class="">> > Yes, config.h is a leftover of old make process which i had to port over<br>
> > to cmake build process without need to do big changes in source code.<br>
> > I am strong opponent of idea that configuration variables shall<br>
> > automatically , dynamically and implicitly change depending on where you<br>
> > compiling the code. Configuration , as a whole can change, but not its<br>
> > variables.<br>
> > They must be defined once and stay same regardless of building environment.<br>
> ><br>
> > That gives you a better chances that software which you successfully built<br>
> > using same configuration will work identically no matter who or where is<br>
> > built it.<br>
> > And sure thing, for having variations, you can define own configuration<br>
> > e.g. MyVMWith(orWithout)UUID<br>
> > and use it to compile VM with that flag changed.<br>
> > But as i say, key here that this flag is set by your hand once and<br>
> > forever, not by some pre-build configure script which depends on where it<br>
> > runs on.<br>
> ><br>
><br>
</div><div class="">> Depends what you're talking about. In this case some linuxes have<br>
> /usr/include/uuid.h and a program called uuidgen, others have<br>
> /usr/include/uuid/uuid.h and a program called uuidgenerate (let alone other<br>
> unixes). IMO it is not the business of a VM source generation pass to<br>
> decide this. It is a compile-time configuration pass.<br>
><br>
</div><div class="">> The approach of having lots of configurations determined at VM source<br>
> generation time leads to VM source which becomes obsolete, is inflexible,<br>
> is duplicated. There needs to be a sensible split. VM generation time is<br>
> not the time to choose things like sets of plugins, particular include file<br>
> locations. IMO it should only produce a full suite of source. A build<br>
> directory is the place to decide what plugins to choose etc, allowing<br>
> special configurations for special uses (an embedded device vs a desktop<br>
> OS, etc). Compile time configuration is the time to choose include files,<br>
> library names etc, etc.<br>
><br>
<br>
</div>Philosophical points of view aside, I have the uncomfortable feeling that<br>
some (all?) of the people in this discussion may have never bothered to look<br>
at how Ian's CMake build actually works.<br>
<br></blockquote><div><div><br></div><div>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..<br></div>I just did one more logical step: generate cmake files on the fly from smalltalk instead of manually editing files. <br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
To put it simply: It implements the approach that Eliot is trying to advocate.<br>
And it works.<br>
<br>
My own personal opinion: Philosophically, I tend to favor Igor's point of view<br>
(put things in the image as much as possible). But in practice, this is a case<br>
where the implementors of CMake are in a better position to deal with platform<br>
differences than we (the Squeak/Pharo community) can afford to do.<br>
<br></blockquote><div> </div><div>building VM is not responsibility of cmake implementors.<br></div><div>And of course, you can use whatever cmake provides.. just keep that knowledge in image, not in files.<br></div><div>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Furthermore, the organization that Ian created puts the responsibilities<br>
where they belong, with minor customizations for the various plugins and<br>
modules located in their respective platform source directories where needed,<br>
and overall control of the CMake configuration and build located in a small<br>
set of CMake files.<br>
<br>
To speak plainly, I have a hard time understanding why something that is well<br>
designed and implemented by its original author needs to be reengineered and<br>
reimplemented by every new person with a new opinion. Why not just support and<br>
contribute to the original author? What's so difficult about that?<br>
<br></blockquote><div> </div><div>At the time i started, there was no CMake configs adopted to work to build Cog VM.<br></div><div><br></div><div>And in general, there is a rule of thumb:<br></div><div> - 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.<br>
</div><div>Same applies to CMake, Makefiles etc..<br></div><div><br></div><div>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. <br>
</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Dave<br>
<br>
</blockquote></div><br clear="all"><br>-- <br>Best regards,<br>Igor Stasenko.
</div></div>