Re: [Chicken-users] CMake tarballs
On 7/29/06, Brandon J. Van Every [EMAIL PROTECTED] wrote: Since CMake is capable of generating its own tarballs, I'd like to put one up on the Chicken webpage. It is important for people to start trying the build. I believe it is now either beta quality or close to it. Come the next release of Chicken, it doesn't make much sense to distribute the CMake stuff together with the ./configure stuff. They each do the tarball in a different way, and I'm not going to try to make them do it the same way. So that means that during a long transition period, we'd have 2 different tarball distributions, until people become confident in the CMake build. Sorry, but why do we need two different kinds of binary distributions? Isn't the whole point of distributing a binrary to make the used build environment transparent? The cmake build should be (and I'm sure it is, as I've witnessed how much progress went into it) just as bad or as good as the other binary. So I'm rather reluctant to put up yet another binary distro - the whole point about cmake is that it simplifies the build, not because it generates better binaries (IMHO). That the cmake build has to be tested is another thing, of course. But I'm sure developers will try cmake more once it has topped the autotools build in terms of speed and convenience. (I'm using autotools in the moment for most stuff, but this is likely to change soon). -- http://galinha.ucpel.tche.br:8081/blog/blog.ssp ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] CMake tarballs
On 7/30/06, Brandon J. Van Every [EMAIL PROTECTED] wrote: 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 don't think Toby called the build broken, but for a UNIX developer, the canonical way of building a package is ./configure;make;make install and any change in that means some getting used to. It will come, once cmake gets more attention. But configuring and building software is something that can get annoying quickly, as we all have surely experienced, so I can understand anybody who gets sensitive when a time-proven build step does something that moves away from the usual path, even if superior (I like ccmake, for example. It has a few quirks, but it is a good idea). 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. But cmake is not a standard component yet. That can be a problem. On the other hand it builds fine on all platforms I have access to. Oh, and don't tell people on this list to contribute to something other than Chicken, please! ;-) 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. Indeed, Windows builds are the main reason why I think CMake is so useful. There were times when I thought Windows is a homogenous platform - Boy, was I wrong: MSVC, MinGW, Cygwin, ... It's a mess, built around an operating system that isn't exactly broken, but doesn't give any decent support for development either. UNIX is a mess as well, sure, but it's messyness is older, and people have put a lot of brain into finding a solution (autotools) that works, most of the time. CMake isn't even a usual solution for Windows. Neither is Chicken. Nor Darcs. You do have a point here. The reason is that Windows has no usual solution, Windows is a non-developer platform. 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. The SCons stuff was about building programs compiled with Chicken, not Chicken itself, IIRC. 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. Please lets not start accusing each other. Lets keep this technical, ok? 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. Yes, it's there and I'm really pleased by their offer. Still, a non-dashboard, fully chicken-based testing method is what I personally prefer, to be honest, to allow things like comparing benchmark results, etc. 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. There are polemics everywhere, in the UNIX world as in the Windows world. There are polemics on this mailing list. I'm a polemic myself. Do you realize that the reason I got started on CMake in the first place is because Felix felt
Re: [Chicken-users] CMake tarballs
felix winkelmann wrote: On 7/29/06, Brandon J. Van Every [EMAIL PROTECTED] wrote: Since CMake is capable of generating its own tarballs, I'd like to put one up on the Chicken webpage. It is important for people to start trying the build. I believe it is now either beta quality or close to it. Come the next release of Chicken, it doesn't make much sense to distribute the CMake stuff together with the ./configure stuff. They each do the tarball in a different way, and I'm not going to try to make them do it the same way. So that means that during a long transition period, we'd have 2 different tarball distributions, until people become confident in the CMake build. Sorry, but why do we need two different kinds of binary distributions? This seems to be confusing the issue. I thought the parlance was, a Chicken tarball is not a binary, it is a source tree with .c files that does not require Chicken in order to build it. The CMake build has this capability now. However, it generates a different tarball than ./configure does. It doesn't put .c files in the same places; this is necessary to support CMake's two-stage bootstrapping and out-of-directory build capabilities. Windows VC++ is the only platform on the Chicken homepage that has a binary. I suppose some other binaries are lurking about in the form of Linux distros. Don't know if anyone has taken on the Cygwin distro. MinGW is a valid binary target, quite apart from VC++. Whether distributed as binary or a source tarball, currently only CMake can build it. Building the VC++ binary with CMake would also be wise if it works, as it would allow us to get rid of the makefile.vc build. I thought it would be sensible to distribute different tarballs since they have different capabilities. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] CMake tarballs
On 7/31/06, Brandon J. Van Every [EMAIL PROTECTED] wrote: Sorry, but why do we need two different kinds of binary distributions? This seems to be confusing the issue. I thought the parlance was, a Chicken tarball is not a binary, it is a source tree with .c files that does not require Chicken in order to build it. The CMake build has this capability now. However, it generates a different tarball than ./configure does. It doesn't put .c files in the same places; this is necessary to support CMake's two-stage bootstrapping and out-of-directory build capabilities. Oh, damn. Yes, of course you where talking about tarballs. I should pay more attention. Is there *some* way to have a single tarball layout? In what directories do you need to put the files? I don't want different tarballs for different build tools, that's silly. So we have to make them equivalent and distribute a single one. cheers, felix -- http://galinha.ucpel.tche.br:8081/blog/blog.ssp ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] CMake tarballs
felix winkelmann wrote: Oh, and don't tell people on this list to contribute to something other than Chicken, please! ;-) Heh! All will henceforth contribute to automagical Chicken packaging systems. Indeed, Windows builds are the main reason why I think CMake is so useful. There were times when I thought Windows is a homogenous platform - Boy, was I wrong: MSVC, MinGW, Cygwin, ... It's a mess, built around an operating system that isn't exactly broken, but doesn't give any decent support for development either. UNIX is a mess as well, sure, but it's messyness is older, and people have put a lot of brain into finding a solution (autotools) that works, most of the time. Autotools could have solved Windows build problems eons ago. The Free Software Foundation does not want it to happen. They want Windows to die, and anything that uses VC++ to die. They are intensely political, and I didn't appreciate the depth of this until I got on the Autoconf mailing list a few years ago. Their phrase, It would harm the GNU Project spoke volumes to me. The FSF has benefited the world with a lot of tools, and has caused things to happen that otherwise wouldn't have happened. But they've also had blind spots due to their politics. Other open source developers who don't entirely believe in their ideology have moved into the niches they don't want to be part of. Linux, CMake, and Eclipse are all examples of this. Yes Linux is GPLed, yes it's 80% GNU tools. But organizationally, Linus Torvaldis got something done that RMS never got done with the GNU Hurd. People who want results move beyond pure ideology. It's good what the FSF has given the world, but I sure don't care to work with them. They want all software licenses to be ideology and social movement. They are opposed to people making their own business decisions and just developing things that work. So fortunately, there are other open source cultures and we don't require the FSF for everything. CMake solves the problem that the FSF won't solve. The reason CMake isn't more popular is because Autoconf has such a huge installed base. But I think in the next decade, Autoconf will be seen as increasingly archaic. More projects will move to better build systems, CMake or otherwise. CMake isn't even a usual solution for Windows. Neither is Chicken. Nor Darcs. You do have a point here. The reason is that Windows has no usual solution, Windows is a non-developer platform. Well, Visual Studio, VC++, and C# are usual. But what of it? They're also limited. Windows development culture is end user centric. This can make it rather painful for developers. On the other hand, you have a lot more options for commodity hardware support. That's one thing that Windows does do a lot better than any of the Linux distros I've seen. A lot of the functional programming crowd I hang out with in Seattle prefers Macs. They offer the power programmer stuff + far better ease of use for devices and stuff. You pay for it though, and it's almost irrelevant as a consumer gaming platform. I hang out on Windows only because I think I'm going to ship games on it. 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. Yes, it's there and I'm really pleased by their offer. Still, a non-dashboard, fully chicken-based testing method is what I personally prefer, to be honest, to allow things like comparing benchmark results, etc. Sure, fine, whatever. Someone do the work. You said you didn't want to, and I don't want to either. I want someone else to do some heavy lifting so I can get on with OpenGL stuff. Which I've had a damn hard time getting started on this past week, because it isn't the same CMake drill I've been doing for 9 months. 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. There are polemics everywhere, in the UNIX world as in the Windows world. There are polemics on this mailing list. I'm a polemic myself. There are degrees of it, and you can't hold a candle to the GNU bigots, frankly. I'd like to see you try. And I say it again: autotools SUCKS SUCKS SUCKS. It's hideous, m4 is brain-damaging, thousand-line shellscripts are sick, fighting with autotools-versions is annoying, and reading the official book (GNU Autoconf, Automake and
Re: [Chicken-users] CMake tarballs
felix winkelmann wrote: On 7/31/06, Brandon J. Van Every [EMAIL PROTECTED] wrote: Sorry, but why do we need two different kinds of binary distributions? This seems to be confusing the issue. I thought the parlance was, a Chicken tarball is not a binary, it is a source tree with .c files that does not require Chicken in order to build it. The CMake build has this capability now. However, it generates a different tarball than ./configure does. It doesn't put .c files in the same places; this is necessary to support CMake's two-stage bootstrapping and out-of-directory build capabilities. Oh, damn. Yes, of course you where talking about tarballs. I should pay more attention. Is there *some* way to have a single tarball layout? Sure. I suggest creating /boot/*.c.in files as the CMake build does. That way, people won't get confused about .c files in their toplevel directory, whether those were built in-directory or came with the tarball, etc. In what directories do you need to put the files? I don't want different tarballs for different build tools, that's silly. No it is not silly, because... So we have to make them equivalent and distribute a single one. ...when you say we, do you mean you? Unless you are willing to work on ./configure, or you can goad some other ./configure expert into doing it, these builds ain't gonna merge. I'm not a ./configure expert and I'm not going to become one. I'll handle stuff that needs to happen on the CMake side, that is easy for me. But learning ./configure in detail is a complete waste of my time and defeats the purpose of my last 9 months. If I had any intention of dealing with ./configure that much, I would have done it 9 months ago. It would be quite sensible to distribute 2 builds to save work. It's sensible to have no conflation of issues, i.e. nobody half-building with ./configure then switching to CMake because something went wrong on MinGW, then half-arsing the whole thing in their bug report. No getting confused about which set of directions to follow. No deadcode paths, where say the distribution/release.setup code is being exercised, the dist.cmake code isn't, and the CMake build is always being broken on check-ins because it's not being exercised regularly. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] CMake tarballs
On 7/31/06, Brandon J. Van Every [EMAIL PROTECTED] wrote: Is there *some* way to have a single tarball layout? Sure. I suggest creating /boot/*.c.in files as the CMake build does. That way, people won't get confused about .c files in their toplevel directory, whether those were built in-directory or came with the tarball, etc. Next question: can the CMake build omit the boot and create the .c files in the toplevel directory? (I know you won't like it, but is it possible?) Anyway, there won't be two different tarballs, so we have to solve this either by modifying either the cmake or the autotools build. cheers, felix -- http://galinha.ucpel.tche.br:8081/blog/blog.ssp ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] CMake tarballs
felix winkelmann scripsit: There were times when I thought Windows is a homogenous platform - Boy, was I wrong: MSVC, MinGW, Cygwin, ... It's a mess, built around an operating system that isn't exactly broken, but doesn't give any decent support for development either. To be fair, I think Windows gives good support for development if you use Microsoft tools and deploy only on Windows. It's not in Microsoft's business interests to make cross-platform development straightforward, with the exception of getting server-side stuff converted from Unix to Windows. But perhaps it's just a personal problem of mine: Shellcode makes me want to close my eyes and think of something differently. Lie back and think of England is the usual advice in these situations. (I don't know whether England here is about nostalgia or patriotism.) -- What has four pairs of pants, lives John Cowan in Philadelphia, and it never rains http://www.ccil.org/~cowan but it pours? [EMAIL PROTECTED] --Rufus T. Firefly ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] CMake tarballs
Brandon J. Van Every scripsit: I do agree with William Hoffman: having a nice language doesn't matter. In that case, hoping that Chicken will catch on is pointless, as it has nothing else to offer. :-) -- On the Semantic Web, it's too hard to prove John Cowan[EMAIL PROTECTED] you're not a dog. --Bill de hOra http://www.ccil.org/~cowan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] CMake tarballs
felix winkelmann wrote: On 7/31/06, Brandon J. Van Every [EMAIL PROTECTED] wrote: Is there *some* way to have a single tarball layout? Sure. I suggest creating /boot/*.c.in files as the CMake build does. That way, people won't get confused about .c files in their toplevel directory, whether those were built in-directory or came with the tarball, etc. Next question: can the CMake build omit the boot and create the .c files in the toplevel directory? (I know you won't like it, but is it possible?) The CMake build does have to remain two-stage, so omit is the wrong word here. I can change the directory structure so that the boot stuff gets done in the main directory, and the final output gets done in a /stagetwo directory. This would allow ./configure to avoid messing with any directory structure issues. *.c vs. *.c.in is still an issue though. What I'd like ./configure to do, is distribute *.c.in files, and copy them at configure time to .c files. That keeps in-directory and out-of-directory builds from getting clobbered. How doable is this from your perspective? Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] CMake tarballs
John Cowan wrote: Brandon J. Van Every scripsit: The CMake tarball should have a name that's different from the ./configure tarball. Perhaps something like chicken-2.41c.tar.gz with the "c" standing for CMake. That looks like version 2.41c, which is not good. chicken-cmake-2.41.tar.gz will fly better with various automated archiving tools that know that the final "*.tar.gz" is the version number and format. What tools are these? Do they handle forks or variants? If they only handle one true version, that's not very useful. I'm not keen on naming the build in a way that looks "unofficial" or "special" or "different." As in, "what the hell is this -cmake- thing??" I want people to just use the build. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] CMake tarballs
John Cowan wrote: Brandon J. Van Every scripsit: What tools are these? Do they handle forks or variants? If they only handle one true version, that's not very useful. They're used by ibiblio that I know of for sure, and probably other standard repositories as well. Forks and variants are handled by changing the name part of the "name-version.format" style. Note that the name can contain hyphens and the version and format can contain periods (as in "tar.gz"). The assumption made is that if you have foo-bar-123.tar.gz and foo-bar-124.tar.gz (or baz-12a.zip or baz-12b.zip), the first of each pair has been superseded by the second. So chicken-2.41c would look like a later version than chicken-2.41, which is not the case. I think I could live with chicken-c-2.41.tar.gz. I'm not keen on naming the build in a way that looks "unofficial" or "special" or "different." As in, "what the hell is this -cmake- thing??" I want people to just use the build. But it *is* an unofficial build, at least for now. Well why don't I name it chicken-dont-use-this-its-unofficial-2.41.tar.gz then? I'm not interested in an unappetizing name, if such names there be. It will never become official if it is not consumed. And of course it relies on the user already having cmake or being willing to install it. Testily, I say, so what? It also relies on people having a friggin' C compiler, a minimum level of technical literacy, and probably other things. The same is true of autoconf/automake, of course, but those are more widely distributed so far. It only relies on people having a Unix shell. Convenient, but it sure makes people lazy. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] CMake tarballs
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. On Sun, Jul 30, 2006 at 09:40:01AM -0700, Brandon J. Van Every wrote: John Cowan wrote: Brandon J. Van Every scripsit: I'm not keen on naming the build in a way that looks unofficial or special or different. As in, what the hell is this -cmake- thing?? I want people to just use the build. It *is* special, different, and unofficial. I agree with John -- 2.41c looks like a version number. Even chicken-c-2.41 is too cryptic for me. I'd rather have it be clear -- chicken-cmake-2.41. On Sun, Jul 30, 2006 at 09:40:01AM -0700, Brandon J. Van Every wrote: Well why don't I name it chicken-dont-use-this-its-unofficial-2.41.tar.gz then? I'm not interested in an unappetizing name, if such names there be. It will never become official if it is not consumed. If you're rather use chicken-dont-use-this-its-unofficial, go right ahead. ;) I, for one, am not interested in making Chicken even more obscure by requiring an obscure build tool. On *every* platform except non-Cygwin, non-MSYS, straight Windows, autotools does the job just fine. IMHO, one platform -- for which two viable workarounds exist -- should not drive a shift that will require everyone else -- those that *have* been able to build up to this point, just by typing ./configure; make; make install -- to go out and get some newfangled installer for the same job. CMake isn't even a usual solution for Windows. 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.) If I had to run chicken on windows, I certainly wouldn't be itching to build it from scratch. There isn't even a C compiler on a Windows machine, by default... How is that sane? 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. Autotools by design doesn't have to be installed... it generates a shell script and makefiles that work anywhere with a reasonable development environment. Testily, I say, so what? It also relies on people having a friggin' C compiler, a minimum level of technical literacy, and probably other things. No need to be snippy. Yes, it requires a C compiler, which every system EXCEPT Windows ships with already installed. On Unix, requiring CMake, which isn't a usual addition, would be more work. Increasing the work on Unix to decrease the work necessary on a system that doesn't come with a C compiler just sounds backwards. Hey, we could probably compile it on the N64... let's make the Unix process harder so N64 takes a step or two less. I'll grant that having Windows binaries is important. But building from scratch? ...not so much. It only relies on people having a Unix shell. Convenient, but it sure makes people lazy. I don't see how having a Unix shell makes me lazy. Because I can install Chicken with a simple ./configure; make; make install? Do you whip yourself every time you install a program with an InstallShield wizard, for being so lazy? So there it is. Is it lamentable that the build process on Windows isn't *easy*? Yes. Is it Chicken's fault? No. Would it be a showstopper for Chicken to be used or even be popular on Windows? No. Windows people tend to be perfectly happy without compiling things in the first place. Don't get me wrong. Having a CMake build can be nothing but an asset. But pushing so hard for it to be the official way to build is too much. 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. -- Toby Butzon ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] CMake tarballs
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
Re: [Chicken-users] CMake tarballs
Toby Butzon scripsit: I, for one, am not interested in making Chicken even more obscure by requiring an obscure build tool. On *every* platform except non-Cygwin, non-MSYS, straight Windows, autotools does the job just fine. Autotools is a pair of kludges piled on a kludge. And Windows is not an obscure and insignificant platform. IMHO, one platform -- for which two viable workarounds exist -- should not drive a shift that will require everyone else -- those that *have* been able to build up to this point, just by typing ./configure; make; make install -- to go out and get some newfangled installer for the same job. You get cmake *once* -- as simple as apt-get cmake or yum cmake or your local equivalent. At worst, you download it from http://www.cmake.org and do ./bootstrap; make; make install. After that, building with CMake is cmake; make; make install, which is *not* more difficult. 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. Autotools by design doesn't have to be installed... it generates a shell script and makefiles that work anywhere with a reasonable development environment. That turns out not to be the case. In fact, I just had to install autoconf and automake on my Solaris test system in order to be able to build the darcs head. (I skipped installing darcs itself by doing a darcs pull on a system -- a Windows system -- that does have darcs and then tarring up the result.) Luckily, someone had already installed gcc and GNU make already, so I didn't have to go through all that just starting from the native Solaris toolchain. For that matter, the native Solaris make will accept the Makefile constructed by CMake, but not the one constructed by autotools.) Don't get me wrong. Having a CMake build can be nothing but an asset. But pushing so hard for it to be the official way to build is too much. The *only* reason that I'm not pushing as hard as I can to make CMake the regular build process *right now* is that it doesn't build properly on Cygwin, which is my chosen environment. Why? Because it's measurably faster to build, easier to understand, and much easier to maintain. It's just a better build system. -- John Cowanhttp://ccil.org/~cowan[EMAIL PROTECTED] SAXParserFactory [is] a hideous, evil monstrosity of a class that should be hung, shot, beheaded, drawn and quartered, burned at the stake, buried in unconsecrated ground, dug up, cremated, and the ashes tossed in the Tiber while the complete cast of Wicked sings Ding dong, the witch is dead. --Elliotte Rusty Harold on xml-dev ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] CMake tarballs
John Cowan wrote: The *only* reason that I'm not pushing as hard as I can to make CMake the regular build process *right now* is that it doesn't build properly on Cygwin, which is my chosen environment. It doesn't? I thought we nailed the dynamic loading nomenclature problem. Is there some other problem? Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] CMake tarballs
Brandon J. Van Every scripsit: It doesn't? I thought we nailed the dynamic loading nomenclature problem. Is there some other problem? No, the same issue. It loads -- you solved the file not found problem -- but then it crashes with nursery too small, which Felix says is a symptom of loading libchicken twice under different names. So I'm still building both ways and then installing the autotools version as my working version. -- Babies are born as a result of the John Cowan mating between men and women, and most http://www.ccil.org/~cowan men and women enjoy mating. [EMAIL PROTECTED] --Isaac Asimov in Earth: Our Crowded Spaceship ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] CMake tarballs
Brandon J. Van Every scripsit: The CMake tarball should have a name that's different from the ./configure tarball. Perhaps something like chicken-2.41c.tar.gz with the c standing for CMake. That looks like version 2.41c, which is not good. chicken-cmake-2.41.tar.gz will fly better with various automated archiving tools that know that the final *.tar.gz is the version number and format. -- What is the sound of Perl? Is it not the John Cowan sound of a [Ww]all that people have stopped [EMAIL PROTECTED] banging their head against? --Larryhttp://www.ccil.org/~cowan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
