Re: [Chicken-users] CMake tarballs

[Brandon J. Van Every]

Toby Butzon wrote:

I've come close to responding to this notion that we're headed for CMake
being "the" way to build Chicken, and I've chosen to keep my mouth shut.
But it seems like we're moving in that direction simply because there
isn't much resistance. So, I'll go on and make it clear that there is.
  

Is your resistance based on actually using the CMake build?  Tell me what's broken about the build, not how you can't be bothered to download a CMake package.  Generally, in open source, when some people do large things of general benefit, other people are expected to do small things for personal benefit.  That's the calculus of how anything gets done.

I, for one, am not interested in making Chicken even more obscure by
requiring an obscure build tool.

CMake 2.4.2 is readily obtained in various Linux distros.  That's not every Unix out there but it's a lot of 'em.  If your Unix doesn't have a packaging system, perhaps you should contribute your open source energies to one. 

 On *every* platform except non-Cygwin,
non-MSYS, straight Windows, autotools does the job just fine.
  

Emphasizing "every" while leaving out MSYS and VC++ - particularly the latter - is just Unix bigotry.  The fact of the matter is, half the world uses VC++ for stuff.  Having a build that handles all versions of VC++, without needing to write separate special stuff, is advantageous to Chicken's future.  Heck, in the CMake universe, sometimes I have to entertain VC++ yokels who don't think Unix is very important, that CMake should just orient itself around handling all the different flavors of VC++ because that's so inherently useful.  Fortunately, the CMake developers know what the term "cross-platform" means, so VC++ bigots and Unix bigots are never taken seriously.

CMake isn't even a "usual" solution for Windows.

Neither is Chicken.  Nor Darcs.  Give me something substantive.

 Creating a CMake
build isn't going to make Chicken internals development on Windows any
less obscure. (For most people, just having a Windows binary would be
plenty. They couldn't care less if it was built on mingw.)

I'm happy to work on shipping binaries and packages for all platforms.  This has nothing to do with the build system.  It has more to do with removing hardwired default pathnames from the source code.

There isn't even a C compiler on a Windows machine, by
default... How is that sane?
  

Since when did the universe owe you a preinstalled C compiler?  I'm impressed enough that there are free ones out there.

John Cowan wrote:
    

And of course it
relies on the user already having cmake or being willing to install
it.
      

Exactly. Why would I want to install CMake so I can build on a system
that actually allows me to have a real build environment.

What you mean is a Unix build environment.  BTW there are other build cultures out there.  Aside from Autotools and CMake, SCons and Ant are notable ones.  Someone was even working on a Chicken SCons thingy, about the time I got started with CMake.  I have not heard anything about that in awhile, so I assume it was either abandoned or not much effort is being put into it.

See, it's like this.  If you personally work on Chicken builds, and make everything work right for everyone else, and put tons and tons of hours into it, then you can get other people to use your tools.  That's how open source works.  If you personally had actually fixed the ./configure build for MinGW / MSYS in the past 9 months, and kept the VC++ build running as well, then I'd be doing things your way and would never have embarked upon this.  Instead, MinGW and VC++ were always breaking.  Energy had to go into fixing the Chicken source itself, not just the build system.  MinGW still breaks under ./configure, nobody's doing anything about it.

When you raise trivial objections, it is called "stop energy."  Here's a RFC on stop energy: http://www.userland.com/whatIsStopEnergy  Being a proponent of Stop Energy is not something to be proud of. 

Do you whip
yourself every time you install a program with an InstallShield wizard,
for being so lazy?
  

Incidentally, CPack,  http://www.cmake.org/Wiki/CMake_Packaging_With_CPack although underdocumented, can apparently create installation packages for every platform.  Useful for shipping binaries if such we choose.  ;-)

And there's the Dart Dashboard stuff for testing and web reportage, if anyone's actually interested enough in that to do the work.  I'm more concerned with OpenGL at present, and would like others to step up for such things.  The offer from Kitware to do the server-side hosting is there though.

Finally, the CMake guys give real support and assistance with their stuff.  I've not worked with a more responsive open source team.  I went with CMake as much for the people as the technology.  In contrast, the GNU crowd is exceedingly difficult to work with, full of polemics.  I offered to wrap VC++ for them once, using code from 2 different available open source solutions.  They refused.  "It would harm the GNU Project," they said.

So there it is. Is it lamentable that the build process on Windows isn't
*easy*?

It is easy... with CMake.

Don't get me wrong. Having a CMake build can be nothing but an asset.
  

Do you realize that the reason I got started on CMake in the first place is because Felix felt the ./configure build... well, how shall I put this... sucked?  Like, it was written by somebody else, he didn't know what was going on with it, didn't really want to know, and said if he could do it over he would.  So 9 months ago I ran with that.  Now we are where we are today.

But pushing so hard for it to be the official way to build is too much.
  

In Your Opinion.  I can have a civilized debate on that, if you have substantive objections.  But complaining how you just don't wanna download a CMake binary doesn't cut it, compared to the enormous work of maintaining reliable multi-platform builds.  Many distros have CMake, it's not tough to obtain.  Tell me what the CMake build isn't accomplishing, or what Autotools can do that CMake can't.  Aside from enabling you to never lift a finger to install anything, or never having to RTFM because you already are familiar with ./configure.

It's fine if you want to support it... I hope lots of people find it
useful, and I hope it gives you satisfaction to contribute. Just try not
to be too heavy handed about it... chucking autotools would not be a
good move.

  

Chucking autotools will be a fantastic move when the CMake build has proven, after a very long testing period, that it does everything the autotools did, only better.  I'd say that will take 6..12 months of testing in the field.  That's not heavy handedness, that's due caution.


Cheers,
Brandon Van Every