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@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@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