[Vm-dev] VM Maker: CMakeVMMakerSqueak-tty.126.mcz

[David T. Lewis]

Hi tty,

I am not sure that I can give you the answer you need, but my expectation
is that the current build system for Cog/Spur is going to be significantly
revised or replaced in the near future. It might make sense for you to wait
a bit and see what direction that takes.

Dave


On Sun, Jul 10, 2016 at 07:45:01PM -0400, gettimothy wrote:
>  
> Hi David,
> 
> This is a resend of an email I sent earlier.
> 
> RE:
> 
> ---- On Mon, 20 Jun 2016 19:05:23 -0400 David T. Lewis <lewis at mail.msen.com> wrote ---- 
> 
>  
> On Mon, Jun 20, 2016 at 10:06:28PM +0200, Holger Freyther wrote: 
> > 
> > 
> > > On 18 Jun 2016, at 23:28, commits at source.squeak.org wrote: 
> > > 
> > > 
> > > Timothy M uploaded a new version of CMakeVMMakerSqueak to project VM Maker: 
> > > http://source.squeak.org/VMMaker/CMakeVMMakerSqueak-tty.126.mcz 
> > 
> > Hi, 
> > 
> > I might be teared and feathered but what would it take to maintain the CMakeLists.txt directly in git and not of generate them from Smalltalk? 
> > 
>  
> That is exactly how Ian Piumarta's CMake build system has been working 
> for the last 6 years or so. It is done with a relatively small amount of 
> CMake scripting code, and has been working reliably with only minimal 
> maintenance since it was first put in place. 
>  
> My earlier comments on this topic are here (my references to the Subversion 
> repository would now pertain to the new Github repository): 
>  http://lists.squeakfoundation.org/pipermail/vm-dev/2014-May/015313.html 
>  
>  
> > From my limited point of view it seems cmake supports targeting multiple platforms/configurations from within the CMakeLists. And when trying to build the PharoVM on FreeBSD I had a lot of trouble[1] and waited[2] a bit too much. 
> > 
>  
> Yes, that is the purpose of CMake. It is designed to be a platform independent 
> build tool. If you find yourself creating large quantities of platform specific 
> CMake scripts, it is a sign that something is wrong. 
>  
> So it certainly does make sense for the CMakeLists to be maintained and 
> versioned along with the source code to which they apply. No need for any 
> tar and feathers IMHO :-) 
>  
> Dave 
>  
>  
>  
> > kind regards 
> > 
> >     holger 
> > 
> > 
> > 
> > [1] Trouble in the sense that the generated paths were absolute, that some CFLAGS didn't apply to the compiler used. 
> > 
> > [2] I seem to have failed to just generate the CMakeLists.txt/* and decided to generate everything which took some time. E.g. the files not being truncated before they are written to 
> 
> 
> 
> There is a good chance that you and holger are correct. Also, the CMakeVMMakerSqueak itself will need crowd-sourcing to build out the various build types, so,  since crowd-sourcing needs to be done, why not do it directly an example CMake build tree (I have 3 that can be generated) and use the git for developing them?
> 
> There is significant work remaining to get the CMakeVMMakerSqueak use documented, simplified (and some refactoring in plugins to be done). I would rather avoid that work (and move on to other projects)  if the community can make better progress with straight CMake build scripts.
> 
> Let me know what your decision is. 
> 
> cheers,
> 
> t
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>