[Chicken-users] understanding the CMake build
John Cowan wrote: Brandon J. Van Every scripsit: Actually, it does matter to us whether you or Brandon are getting burned out: it would be a huge job to take over supporting even the CMake build >from zero, Actually I don't agree. I didn't do the "write obscure code so that I remain invaluable" thing, I did rather the opposite. :-) The CMake build is currently feature complete, and it's MIT licensed, so you simply can't start "from zero." It would be understanding and support that would have to start from zero, not coding. And FLOSSfolk have seen repeatedly that unless there's a maintainer, people stay away from projects, because of the often well-founded suspicion that nobody knows what's going on. That's true. I'm currently the only CMake expert, although I do have confidence that in time, Felix will pick up what he needs. I wonder, why would anyone else want to understand the CMake build? Unless they wanted to extend it, I can't think of a reason. Even a core Chicken language developer could get by with very little understanding of the build, if they were working on an aspect of Chicken that doesn't have build-visible effects. Turning the build into a CMake tutorial, and pushing it at Kitware via CMake-Promote, does sound like a good idea. It would attract people who aren't really interested in Chicken, but who want to learn CMake. It would make the build easier to understand. Other things are needed as well though. CMake online documentation in general is poor. The mailing list is great, you can get all your questions rapidly answered there, but documentation is definitely a serious shortcoming. Not that people are better off with Autotools. It's better documented, but the whole toolchain will drive you nuts. You still need those hunting and pecking skills, because you have to figure out whether what you want to do is an Automake thing, an Autoconf thing, a Libtool thing, or a GNU Make thing. I crash learned Automake over the past 3 weeks, already knowing what I wanted the build to do from the CMake side, and already having an Automake build that worked but wasn't unified in the Chicken build tree. I can't imagine getting motivated to write an Automake build from scratch! Anyways, the reality is I don't have time for tutorializing the CMake build right now. Nor will it be my 1st priority when I do have time. 1st priority is OpenGL and games. Actually, those could become vectors for both CMake and Chicken promotion. This is all very future-looking though. Pretty much the same reason why the CMake online docs don't improve; everyone's too busy with something more important. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: CMake problem on Linux should be solved
Drat. I was hoping that file level dependencies would cross subdirectory boundaries. They seem to do it on MinGW, Cygwin, and VS71 - or else the build order just happens to work on those platforms. Do file dependencies not cross subdirectories on Linux? Even on the Windows targets, I had to specify the file dependencies as GENERATED to get CMakeSetup to quit complaining. Previously I've not had to do that, but previously, .scm --> .c was always done in the same directory. I can put custom targets back in to force the .c files to be built. But I'd like to know if this is a bug or expected behavior. Lately I've been avoiding "target wrapping paranoia," that is, the tendency to wrap up all file dependencies in custom targets for fear that file dependencies won't be honored. It'll be nice if someday the file dependencies and target dependencies are handled in the same way. Cheers, Brandon Van Every William A. Hoffman wrote: I got this error: make[2]: *** No rule to make target `match.c', needed by `static/CMakeFiles/libchicken-static.dir/depend.make.mark'. Stop. make[1]: *** [static/CMakeFiles/libchicken-static.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs At 09:39 PM 9/7/2006, Brandon J. Van Every wrote: CMake 2.4.3 has a bug where static and dynamic libraries clobber each other during the build if they have the same rootname. The bug affects all OSes. Previously I thought it only affected Windows, and I implemented hacks during the INSTALL to get around it. Felix reported a problem on Linux and Bill of Kitware confirmed that it's the same bug. I decided it is too complicated to do more INSTALL hacks, as I don't really know what suffixes are apropos on Linux or arbitrary OSes in general, nor do I have the ability to test them. So, static libraries are now built in a /static subdirectory. This took some refactoring of CMakeLists.txt. It wasn't trivial but it was doable, about a day's work. The results are now in Darcs. I have confirmed that VS 7.1, MinGW, and Cygwin all build and install just fine now. I am projecting that Linux will build and install just fine now as well, since it will go through the same code path as the MinGW build. I await your tests. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] CMake problem on Linux should be solved
Brandon J. Van Every scripsit: > >Actually, it does matter to us whether you or Brandon are getting burned > >out: it would be a huge job to take over supporting even the CMake build > >from zero, > > Actually I don't agree. I didn't do the "write obscure code so that I > remain invaluable" thing, I did rather the opposite. :-) The CMake > build is currently feature complete, and it's MIT licensed, so you > simply can't start "from zero." It would be understanding and support that would have to start from zero, not coding. And FLOSSfolk have seen repeatedly that unless there's a maintainer, people stay away from projects, because of the often well-founded suspicion that nobody knows what's going on. > Yes, that matters. My strategic thought has been, it's BSD licensed > code, and I do have an interest in writing compilers. So maybe 2 years > from now, I'll know the implementation well enough that in the worst > case, it won't matter to me what Felix is doing. Right now I'd be toast > though. Chicken *is* fully understandable by 1 person. The question is, is there anyone who has both the motivation and the time? I don't hear anyone, so that's why your and Felix's state of mind both matter. -- No, John. I want formats that are actually John Cowan useful, rather than over-featured megaliths that http://www.ccil.org/~cowan address all questions by piling on ridiculous [EMAIL PROTECTED] internal links in forms which are hideously over-complex. --Simon St. Laurent on xml-dev ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] CMake problem on Linux should be solved
John Cowan wrote: felix winkelmann scripsit: I've put 6 years of my free hacking time into this (nothing else), and nobody should give a damn about my personal motivations or how often I get fed up with it, or how it affects my day job. Actually, it does matter to us whether you or Brandon are getting burned out: it would be a huge job to take over supporting even the CMake build from zero, Actually I don't agree. I didn't do the "write obscure code so that I remain invaluable" thing, I did rather the opposite. :-) The CMake build is currently feature complete, and it's MIT licensed, so you simply can't start "from zero." I've designed, modularized, and commented it well enough to be used by anyone who has a serious interest in a CMake build system. In fact if I spruce it up a bit, and maybe after CMake 2.4.4 ships so I can remove a workaround or two, it might even serve as good tutorial code for CMake newbies. I might promote both CMake and Chicken that way. I could walk away from Chicken right now, or get hit by a truck, and CMake will prosper if at least 1 person wants to make it prosper. It's the cultural questions that plague me, not the technical ones. The technical ones are solved. My tools for getting people to desire CMake are very limited. I doubt it'll spread like wildfire because it's just a build, and people are awfully "inert" (I want to say lazy, but it's more fair / responsible to say "inert") about what they like to do on a command line. Even on the CMake-Promote mailing list we don't have any magical answers for this problem of adoption. never mind all of Chicken. Felix, if you bail out, Chicken probably dies, and that matters to people who are using it. Yes, that matters. My strategic thought has been, it's BSD licensed code, and I do have an interest in writing compilers. So maybe 2 years from now, I'll know the implementation well enough that in the worst case, it won't matter to me what Felix is doing. Right now I'd be toast though. Chicken *is* fully understandable by 1 person. Felix is right to pitch "Chicken is a small implementation" as one of its advantages, especially compared to Common Lisp. I just don't currently have a spare 1 year to reach that understanding. I don't even have a spare 4 weeks; I gotta stop playing computer guy and start playing ditch digger. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] CMake problem on Linux should be solved
I think we are closer to being on the same page now. felix winkelmann wrote: On 9/8/06, Brandon J. Van Every <[EMAIL PROTECTED]> wrote: We need to agree what the milestones are. Or, you need to tell me what the milestones are gonna be, if you're in a more forceful mood about it. Then I can decide what I'm willing to do about them. I have no milestones, besides getting 2.5 out as soon as I find some time doing testing which includes booting up that despised Windows notebook... There are no new features planned, and whatever I muddle around in configure.in shouldn't concern you, since it is simply not ready. My only concern is whether the "unity" of the build breaks. But I will endeavor to be more trusting and less concerned. You are free to do whatever you want, of course. The CMake support is very good, and I appreciate that and will go out of my way to acknowledge that properly when the next version will be released. If you could just get that idea out of your head that I'm trying to break your work, or whatever. I will admit to being insecure about whether people will adopt my build. I know it is a good build, but there are issues of perception and inertia. Like whether one build is perceived as more stable, more tested, or more feature-rich than the other. You know the old engineering phrase, "Build it, and they will come." Which really means, build it and you'll be ignored. I've never shipped anything with my name on it that a large audience ended up using. I've tried; this is pretty much my "Three Times 'A Charm" project. Also, you should perhaps keep your private interests in supporting Chicken out of the general discussion, as that is something you have to work out for yourself. If you want to contribute, contribute. Don't try to get your personal motiviations into the discussion, please. I've put 6 years of my free hacking time into this (nothing else), and nobody should give a damn about my personal motivations or how often I get fed up with it, or how it affects my day job. Actually it does matter from a "will Felix go nutters?" standpoint. Compare "will Felix be hit by a bus?" A rapid pace of development is a two-edged sword. For instance the lead of the Nebula 2 project was difficult to deal with, really snappy with some bizarre and dictatorial personal views about languages and technologies and so forth. I'm sure this had something to do with having a high stress game development day job and doing lots of Nebula 2 stuff in addition to that. Did he have anything remotely resembling a life? I'd be shocked. Anyways I couldn't work with him. His stress level selected for "partners" that were subordinate and super easy going. Doormats, really. I'm easy going enough, I don't hold grudges, but I do challenge people. This was the kind of guy you'd try to start a design discussion with, weigh some pros and cons, and he'd tell you to STFU. I spent about a year hovering around Nebula 2 before giving up on it. The Ogre 3D engine has risen in popularity in the interim, and also Irrlicht. I wouldn't be surprised if interpersonal dynamics have something to do with that. What I recall of the Ogre message boards, it did seem like a healthier culture than what was going on in Nebula 2. But I never stuck around the Ogre project, I've just Googled their forums occasionally, so my perception may be superficial. Anyways you're easygoing, Felix. I'm just staying that rapid development does create technical stress. Which then can turn into personal stress, for anyone attached to Chicken. In commercial development, people get paid to take the stress. I think the level of stress that open source developers can take is much lower, systemically speaking. I mean, when there's money, you can keep a large team going, put people through certain degrees of pain, and they'll just grind it out for their paychecks. But in open source, when people's pain threshold is exceeded, people just leave. And they leave quietly more often than they leave noisily. So for getting a project to grow bigger, with more long-term committed developers, the level of technical stress does matter. Sure in principle everyone could - should? - "suck it up" and not complain. But in practice, a project lead might end up saying, hm, why am I not attracting more developers? Of course on the flip side, open source developers have to stress themselves. There is no manager to flog them, no paycheck to bait them. Help us with your experience, if you want. But don't complain, as we all are doing our best. This I appreciate more now. I need to decide the level of technical stress I can sustain. For now, I've decided to go into "passive" rather than active mode. I will let bugs sit around for a week before I look at them, instead of acting like a crisis response team. Maybe someone else will solve them meanwhile. Cheers, Brandon Van E
Re: [Chicken-users] CMake problem on Linux should be solved
felix winkelmann scripsit: > I've put 6 years of my free hacking time into this (nothing else), > and nobody should give a damn about my personal motivations or how > often I get fed up with it, or how it affects my day job. Actually, it does matter to us whether you or Brandon are getting burned out: it would be a huge job to take over supporting even the CMake build from zero, never mind all of Chicken. Felix, if you bail out, Chicken probably dies, and that matters to people who are using it. (If I'm wrong about this, will the backup maintainer please stand up?) -- John Cowan [EMAIL PROTECTED]http://ccil.org/~cowan Big as a house, much bigger than a house, it looked to [Sam], a grey-clad moving hill. Fear and wonder, maybe, enlarged him in the hobbit's eyes, but the Mumak of Harad was indeed a beast of vast bulk, and the like of him does not walk now in Middle-earth; his kin that live still in latter days are but memories of his girth and his majesty. --"Of Herbs and Stewed Rabbit" ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: [CMake] setting a default build type
Given a very basic HelloWorld application in Visual Studio, there is only one way that I have found to force it to choose something other than "Debug" by default: eliminate the "Debug" configuration. In the very basic case (generated by Visual Studio wizard) there are only two configurations: Debug and Release. I've re-arranged the bits related to configuration in both the generated sln file and the vcproj file, to no avail. When there is no .suo file and Debug is one of the configurations, Visual Studio chooses it by default. Period. (As far as I can tell...) I have used the following: SET(CMAKE_CONFIGURATION_TYPES "MinSizeRel") to restrict the configurations to 1 and only 1. This works nicely for automated builds when you set the only config type you care about from a script... You could do the same, but then you lose the flexibility of just switching to Debug in the VS IDE... HTH, David Brandon J. Van Every wrote: Brad King wrote: Brandon J. Van Every wrote: Brad King wrote: This would be a nice feature but I don't know how to implement it. Try generating a project and then manually editing the project files in such a way that the IDE selects a different configuration by default. Don't forget to remove the .suo and .ncb files between attempts because they store the user IDE state. That approach is not desired. People typically want CMakeList.txt under source control, not its end products, as the latter differ for every person. We don't ship .sln files to people, we tell them to install CMake. I was not proposing this as a solution, I was asking you to figure out how to implement it. I have no idea how to write a .sln or .vcproj file that will convince the VS IDE to come up with a non-Debug configuration by default. I just tried manually reordering the configurations to put Release first and the IDE still selected Debug at startup. Even changing the Release configuration to have the name ARelease (which comes before Debug lexicographically) didn't fix it. I have no idea either, nor time to investigate it at present. I will note our lack of knowledge in the feature request. Maybe we'll run into someone else who knows better. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: [CMake] setting a default build type
Brandon J. Van Every wrote: > Brad King wrote: >> This would be a nice feature but I don't know how to implement it. Try >> generating a project and then manually editing the project files in such >> a way that the IDE selects a different configuration by default. Don't >> forget to remove the .suo and .ncb files between attempts because they >> store the user IDE state. > > That approach is not desired. People typically want CMakeList.txt under > source control, not its end products, as the latter differ for every > person. We don't ship .sln files to people, we tell them to install CMake. I was not proposing this as a solution, I was asking you to figure out how to implement it. I have no idea how to write a .sln or .vcproj file that will convince the VS IDE to come up with a non-Debug configuration by default. I just tried manually reordering the configurations to put Release first and the IDE still selected Debug at startup. Even changing the Release configuration to have the name ARelease (which comes before Debug lexicographically) didn't fix it. -Brad ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] CMake problem on Linux should be solved
Brandon J. Van Every scripsit: > Are you using CMake 2.4.3 or CMake CVS? If 2.4.3 then we're using the > same CMake. 2.4.3, for the record. -- John Cowan [EMAIL PROTECTED] http://ccil.org/~cowan If I have seen farther than others, it is because I was standing on the shoulders of giants. --Isaac Newton ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken-setup, csc now broken on CMake MinGW
This should be fixed in the current darcs head. cheers, felix On 9/8/06, Brandon J. Van Every <[EMAIL PROTECTED]> wrote: An' I dinna' doit, Felix. Your bad, no idea what. Other stuff builds. - Cheers, Brandon Brandon J. Van [EMAIL PROTECTED] ~/msys/chicken $ make -k [ 14%] Built target libchicken-boot [ 19%] Built target chicken-boot [ 33%] Built target libchicken [ 38%] Built target chicken [ 39%] Built target chicken-profile [ 39%] Building C object CMakeFiles/chicken-setup.dir/chicken-setup.obj E:/devel/msys/chicken/chicken-setup.c: In function `tr6r': E:/devel/msys/chicken/chicken-setup.c:3267: warning: implicit declaration of fun ction `alloca' E:/devel/msys/chicken/chicken-setup.c: In function `f_1653': E:/devel/msys/chicken/chicken-setup.c:12198: error: syntax error before ')' toke n E:/devel/msys/chicken/chicken-setup.c:12198: error: too many arguments to functi on `C_mpointer' E:/devel/msys/chicken/chicken-setup.c:12198: error: syntax error before ';' toke n E:/devel/msys/chicken/chicken-setup.c: In function `f_1657': E:/devel/msys/chicken/chicken-setup.c:12214: error: syntax error before ')' toke n E:/devel/msys/chicken/chicken-setup.c:12214: error: too many arguments to functi on `C_mpointer' E:/devel/msys/chicken/chicken-setup.c:12214: error: syntax error before ';' toke n E:/devel/msys/chicken/chicken-setup.c: In function `f_1661': E:/devel/msys/chicken/chicken-setup.c:12230: error: syntax error before ')' toke n E:/devel/msys/chicken/chicken-setup.c:12230: error: too many arguments to functi on `C_mpointer' E:/devel/msys/chicken/chicken-setup.c:12230: error: syntax error before ';' toke n E:/devel/msys/chicken/chicken-setup.c: In function `f_1665': E:/devel/msys/chicken/chicken-setup.c:12246: error: syntax error before ')' toke n E:/devel/msys/chicken/chicken-setup.c:12246: error: too many arguments to functi on `C_mpointer' E:/devel/msys/chicken/chicken-setup.c:12246: error: syntax error before ';' toke n make[2]: *** [CMakeFiles/chicken-setup.dir/chicken-setup.obj] Error 1 make[2]: Target `CMakeFiles/chicken-setup.dir/build' not remade because of error s. make[1]: *** [CMakeFiles/chicken-setup.dir/all] Error 2 [ 46%] Built target libchicken-static [ 51%] Built target chicken-static [ 52%] Building C object CMakeFiles/csc.dir/csc.obj E:/devel/msys/chicken/csc.c: In function `C_toplevel': E:/devel/msys/chicken/csc.c:1003: warning: implicit declaration of function `all oca' E:/devel/msys/chicken/csc.c: In function `f_461': E:/devel/msys/chicken/csc.c:2268: error: syntax error before ')' token E:/devel/msys/chicken/csc.c:2268: error: too many arguments to function `C_mpoin ter' E:/devel/msys/chicken/csc.c:2268: error: syntax error before ';' token E:/devel/msys/chicken/csc.c: In function `f_2904': E:/devel/msys/chicken/csc.c:2294: error: syntax error before ')' token E:/devel/msys/chicken/csc.c:2294: error: too many arguments to function `C_mpoin ter' E:/devel/msys/chicken/csc.c:2294: error: syntax error before ';' token E:/devel/msys/chicken/csc.c: In function `f_2908': E:/devel/msys/chicken/csc.c:2320: error: syntax error before ')' token E:/devel/msys/chicken/csc.c:2320: error: too many arguments to function `C_mpoin ter' E:/devel/msys/chicken/csc.c:2320: error: syntax error before ';' token E:/devel/msys/chicken/csc.c: In function `f_2912': E:/devel/msys/chicken/csc.c:2346: error: syntax error before ')' token E:/devel/msys/chicken/csc.c:2346: error: too many arguments to function `C_mpoin ter' E:/devel/msys/chicken/csc.c:2346: error: syntax error before ';' token E:/devel/msys/chicken/csc.c: In function `f_499': E:/devel/msys/chicken/csc.c:3115: error: syntax error before ')' token E:/devel/msys/chicken/csc.c:3115: error: too many arguments to function `C_mpoin ter' E:/devel/msys/chicken/csc.c:3115: error: syntax error before ';' token E:/devel/msys/chicken/csc.c: In function `f_506': E:/devel/msys/chicken/csc.c:3246: error: syntax error before ')' token E:/devel/msys/chicken/csc.c:3246: error: too many arguments to function `C_mpoin ter' E:/devel/msys/chicken/csc.c:3246: error: syntax error before ';' token make[2]: *** [CMakeFiles/csc.dir/csc.obj] Error 1 make[2]: Target `CMakeFiles/csc.dir/build' not remade because of errors. make[1]: *** [CMakeFiles/csc.dir/all] Error 2 [ 53%] Built target csi [ 53%] Built target csi-static [ 54%] Built target darcs_changelog [ 69%] Built target libchickengui [ 83%] Built target libuchicken [ 90%] Built target libchickengui-static [ 98%] Built target libuchicken-static make[1]: Target `all' not remade because of errors. make: *** [all] Error 2 make: Target `default_target' not remade because of errors. Brandon J. Van [EMAIL PROTECTED] ~/msys/chicken $ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users -- http://galinha.ucpel.tche.br:8081/blog/blog.ssp ___ Chicken-users mailing list Chicken
Re: [Chicken-users] CMake problem on Linux should be solved
On 9/8/06, Brandon J. Van Every <[EMAIL PROTECTED]> wrote: > > Don't make a political thing out of this, Brandon. We are talking > about the development repository of an actively maintained open source > project. People involved do make mistakes, bugs appear and get fixed > (hopefully). If I made a change to Makefile.am without fixing the > appropriate > section in CMakeLists.txt right away then it was simply by mistake. This is not a confidence I would have previously had, but I will take your word for it in the future. Good. I'm skating eviction for this fucking project. Do you have any idea how much real income I've lost on this? Why you did your contribution and how that works out with your financial situation is not of importance here. You've done good work, work that will make Chicken a better project, and that is all that counts. But I won't let anybody get away with declaring that I'm not trying to do the utmost possible to incorporate valuable contributions, or that I even break things deliberately, even by neglection. This is a difficult stage, because I can't actually make you stop adding new features. You said privately, somewhere like 1..2 weeks ago, that you had broken too many things, wanted a stabilization period for Chicken, and that you now saw CMake as a top priority. That resurrected my flagging morale. Previously, I was starting to think that no matter how much I fix Chicken, there will be double the number of things waiting around the corner to undo it again. So tonight, when I pulled 4 significant looking patches, with substantial looking Autoconf changes for cross-compiling among them, and things broke in several places, I was not happy. It did not look like you had taken me seriously, about the impact it has on my time and finances. But you say it's just a Darcs problem, that you handled what was supposed to be handled, and it just didn't make it in. So this leads me to a different conclusion... Yeah, I'm quick with changes and sometimes commit experimental code, but this is how Chicken is developed, and the pace has made it one of the fastest growing and improving Scheme/Lisp implementations in existance. ...we are not communicating with each other about what we're doing. Darcs is a great enabler for that. It can in principle let our patches fly right past each other. It has worked previously; it is not working anymore. We need to start talking about what we're doing, because the basis of trust is somewhat eroded. But not due to technical issues. Writing and build-system is just a hard thing to do and very complicated, especially with a compiler that bootstraps itself. This silly, tiny issue about parsing the version string in CMakeLists.txt was just a coincidence. Yes, I want more stability, but I also want a system that works well - there is naturally a trade off and fast development has priority (for me, at least). In fact, I think we've done quite well. I am unsure what milestones you are trying to hit. 2 weeks ago, I thought I knew. But we never made any kind of formal agreement on date, time, content, or anything like that. So perhaps you think you're hitting a milestone 1 month from now. Or 2 months from now. I really don't know. I worry that we don't actually share goals. That in practice, you'll just keep designing for Autoconf to get cross-compilers, and CMake will become the biggest "eh" I've ever written. (But at least a BSD licensed "eh.") There is no real cross-compilation support. The stuff modified in the autoconf files was just the start of an experiment - far from being finished. Adding that bit to CMakeLists.txt would be trivial if I just new more about CMake (or if the documentation would be better...). I planned to add it anyway. We need to agree what the milestones are. Or, you need to tell me what the milestones are gonna be, if you're in a more forceful mood about it. Then I can decide what I'm willing to do about them. I have no milestones, besides getting 2.5 out as soon as I find some time doing testing which includes booting up that despised Windows notebook... There are no new features planned, and whatever I muddle around in configure.in shouldn't concern you, since it is simply not ready. > > This is the last warning. > I'm not at the stage of delivering ultimatums. Be advised that I'm capable of them, however. In the worst case, I do have the willingness to write off my past 2 years as a failed experiment in open source business models. There has to be a point at which I can just use the results of my work, and not just end up with more work. I know I won't be repeating the kind of open source investment I've made into Chicken. For instance, regarding Chickenizing G3D, I am very cautious. Not interested in another 10 months. You are free to do whatever you want, of course. The CMake support is very good, and I appreciate that and will go out of my way to acknowledge that properly when t
Re: [Chicken-users] CMake problem on Linux should be solved
felix winkelmann wrote: On 9/8/06, Brandon J. Van Every <[EMAIL PROTECTED]> wrote: Ah, now I see the problem. The banner has changed the format for how it presents >the version number. My regex is surely failing. I have fixed this already this morning around 4:30 , but apparently I must have made a mistake and the patch didn't end up on galinha. Well, my patch is in now. And it is 4 am as I finish this e-mail, BTW. That was not my plan. Felix, it is hereby proven that you didn't touch or even look at CMake when doing your recent Autoconf changes. :-) I was serious about not chasing Autoconf, and not having things "dropped in my lap," especially right now with my financial situation. This one should be easy, but if you drop me something that's hard, I'm simply not going to do anything about it. And I'm going to get very, very irritated if you break things, in some kind of non-trivial manner, that I've been working hard to stabilize. I don't have any half-days to throw at CMake anymore; you will have to do them. So please consider design impacts on CMake. Don't make a political thing out of this, Brandon. We are talking about the development repository of an actively maintained open source project. People involved do make mistakes, bugs appear and get fixed (hopefully). If I made a change to Makefile.am without fixing the appropriate section in CMakeLists.txt right away then it was simply by mistake. This is not a confidence I would have previously had, but I will take your word for it in the future. Please, don't go on like this. Please don't start irritating _me_, as you irritated each and every other open source language implementor. Since you choose to make such aspersions public on this list, you get a public response. If you want to discuss such things privately in the future, that is better. I don't recall irritating Manuel Serrano of Bigloo. Nor do I recall making a 10 month full time contribution to the Bigloo build system. I might feel guilt for having irritated Xavier Leroy of OCaml. I certainly do not feel it for Guido Van Rossum of Python, as once upon a time he was in the process of blasting his best web designer. The end result of that fiasco is Python got a decent looking website 2 years later than it should have. If you're going to buy into the "each and every..." nonsense that gets bandied about Usenet... well, I will refrain from commenting on it further. Let's just say it leaves a very bad taste. I'm working my arse off for this fucking project, you know? I'm skating eviction for this fucking project. Do you have any idea how much real income I've lost on this? This is a difficult stage, because I can't actually make you stop adding new features. You said privately, somewhere like 1..2 weeks ago, that you had broken too many things, wanted a stabilization period for Chicken, and that you now saw CMake as a top priority. That resurrected my flagging morale. Previously, I was starting to think that no matter how much I fix Chicken, there will be double the number of things waiting around the corner to undo it again. So tonight, when I pulled 4 significant looking patches, with substantial looking Autoconf changes for cross-compiling among them, and things broke in several places, I was not happy. It did not look like you had taken me seriously, about the impact it has on my time and finances. But you say it's just a Darcs problem, that you handled what was supposed to be handled, and it just didn't make it in. So this leads me to a different conclusion... ...we are not communicating with each other about what we're doing. Darcs is a great enabler for that. It can in principle let our patches fly right past each other. It has worked previously; it is not working anymore. We need to start talking about what we're doing, because the basis of trust is somewhat eroded. I have a milestone I'm trying to hit. I've been crunching to hit it, thinking, if I just finish this one last item, then I'll be Done. Chicken will be pretty much out of my hair. I can go get my stupid ditch digging job or whatever I have to do to survive right now, knowing that I shipped, that CMake will be Chicken's bright future, and everything will be O.K. I am unsure what milestones you are trying to hit. 2 weeks ago, I thought I knew. But we never made any kind of formal agreement on date, time, content, or anything like that. So perhaps you think you're hitting a milestone 1 month from now. Or 2 months from now. I really don't know. I worry that we don't actually share goals. That in practice, you'll just keep designing for Autoconf to get cross-compilers, and CMake will become the biggest "eh" I've ever written. (But at least a BSD licensed "eh.") We need to agree what the milestones are. Or, you need to tell me what the milestones are gonna be, if you're in a more forceful mood about it
Re: [Chicken-users] CMake problem on Linux should be solved
Brandon J. Van Every wrote: Ah, now I see the problem. The banner has changed the format for how it presents the version number. My regex is surely failing. Solved (even as far back as Chicken 2.3) and pushed to Darcs. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] chicken-setup, csc now broken on CMake MinGW
An' I dinna' doit, Felix. Your bad, no idea what. Other stuff builds. - Cheers, Brandon Brandon J. Van [EMAIL PROTECTED] ~/msys/chicken $ make -k [ 14%] Built target libchicken-boot [ 19%] Built target chicken-boot [ 33%] Built target libchicken [ 38%] Built target chicken [ 39%] Built target chicken-profile [ 39%] Building C object CMakeFiles/chicken-setup.dir/chicken-setup.obj E:/devel/msys/chicken/chicken-setup.c: In function `tr6r': E:/devel/msys/chicken/chicken-setup.c:3267: warning: implicit declaration of fun ction `alloca' E:/devel/msys/chicken/chicken-setup.c: In function `f_1653': E:/devel/msys/chicken/chicken-setup.c:12198: error: syntax error before ')' toke n E:/devel/msys/chicken/chicken-setup.c:12198: error: too many arguments to functi on `C_mpointer' E:/devel/msys/chicken/chicken-setup.c:12198: error: syntax error before ';' toke n E:/devel/msys/chicken/chicken-setup.c: In function `f_1657': E:/devel/msys/chicken/chicken-setup.c:12214: error: syntax error before ')' toke n E:/devel/msys/chicken/chicken-setup.c:12214: error: too many arguments to functi on `C_mpointer' E:/devel/msys/chicken/chicken-setup.c:12214: error: syntax error before ';' toke n E:/devel/msys/chicken/chicken-setup.c: In function `f_1661': E:/devel/msys/chicken/chicken-setup.c:12230: error: syntax error before ')' toke n E:/devel/msys/chicken/chicken-setup.c:12230: error: too many arguments to functi on `C_mpointer' E:/devel/msys/chicken/chicken-setup.c:12230: error: syntax error before ';' toke n E:/devel/msys/chicken/chicken-setup.c: In function `f_1665': E:/devel/msys/chicken/chicken-setup.c:12246: error: syntax error before ')' toke n E:/devel/msys/chicken/chicken-setup.c:12246: error: too many arguments to functi on `C_mpointer' E:/devel/msys/chicken/chicken-setup.c:12246: error: syntax error before ';' toke n make[2]: *** [CMakeFiles/chicken-setup.dir/chicken-setup.obj] Error 1 make[2]: Target `CMakeFiles/chicken-setup.dir/build' not remade because of error s. make[1]: *** [CMakeFiles/chicken-setup.dir/all] Error 2 [ 46%] Built target libchicken-static [ 51%] Built target chicken-static [ 52%] Building C object CMakeFiles/csc.dir/csc.obj E:/devel/msys/chicken/csc.c: In function `C_toplevel': E:/devel/msys/chicken/csc.c:1003: warning: implicit declaration of function `all oca' E:/devel/msys/chicken/csc.c: In function `f_461': E:/devel/msys/chicken/csc.c:2268: error: syntax error before ')' token E:/devel/msys/chicken/csc.c:2268: error: too many arguments to function `C_mpoin ter' E:/devel/msys/chicken/csc.c:2268: error: syntax error before ';' token E:/devel/msys/chicken/csc.c: In function `f_2904': E:/devel/msys/chicken/csc.c:2294: error: syntax error before ')' token E:/devel/msys/chicken/csc.c:2294: error: too many arguments to function `C_mpoin ter' E:/devel/msys/chicken/csc.c:2294: error: syntax error before ';' token E:/devel/msys/chicken/csc.c: In function `f_2908': E:/devel/msys/chicken/csc.c:2320: error: syntax error before ')' token E:/devel/msys/chicken/csc.c:2320: error: too many arguments to function `C_mpoin ter' E:/devel/msys/chicken/csc.c:2320: error: syntax error before ';' token E:/devel/msys/chicken/csc.c: In function `f_2912': E:/devel/msys/chicken/csc.c:2346: error: syntax error before ')' token E:/devel/msys/chicken/csc.c:2346: error: too many arguments to function `C_mpoin ter' E:/devel/msys/chicken/csc.c:2346: error: syntax error before ';' token E:/devel/msys/chicken/csc.c: In function `f_499': E:/devel/msys/chicken/csc.c:3115: error: syntax error before ')' token E:/devel/msys/chicken/csc.c:3115: error: too many arguments to function `C_mpoin ter' E:/devel/msys/chicken/csc.c:3115: error: syntax error before ';' token E:/devel/msys/chicken/csc.c: In function `f_506': E:/devel/msys/chicken/csc.c:3246: error: syntax error before ')' token E:/devel/msys/chicken/csc.c:3246: error: too many arguments to function `C_mpoin ter' E:/devel/msys/chicken/csc.c:3246: error: syntax error before ';' token make[2]: *** [CMakeFiles/csc.dir/csc.obj] Error 1 make[2]: Target `CMakeFiles/csc.dir/build' not remade because of errors. make[1]: *** [CMakeFiles/csc.dir/all] Error 2 [ 53%] Built target csi [ 53%] Built target csi-static [ 54%] Built target darcs_changelog [ 69%] Built target libchickengui [ 83%] Built target libuchicken [ 90%] Built target libchickengui-static [ 98%] Built target libuchicken-static make[1]: Target `all' not remade because of errors. make: *** [all] Error 2 make: Target `default_target' not remade because of errors. Brandon J. Van [EMAIL PROTECTED] ~/msys/chicken $ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] CMake problem on Linux should be solved
On 9/8/06, Brandon J. Van Every <[EMAIL PROTECTED]> wrote: Ah, now I see the problem. The banner has changed the format for how it presents >the version number. My regex is surely failing. I have fixed this already this morning around 4:30 , but apparently I must have made a mistake and the patch didn't end up on galinha. Felix, it is hereby proven that you didn't touch or even look at CMake when doing your recent Autoconf changes. :-) I was serious about not chasing Autoconf, and not having things "dropped in my lap," especially right now with my financial situation. This one should be easy, but if you drop me something that's hard, I'm simply not going to do anything about it. And I'm going to get very, very irritated if you break things, in some kind of non-trivial manner, that I've been working hard to stabilize. I don't have any half-days to throw at CMake anymore; you will have to do them. So please consider design impacts on CMake. Don't make a political thing out of this, Brandon. We are talking about the development repository of an actively maintained open source project. People involved do make mistakes, bugs appear and get fixed (hopefully). If I made a change to Makefile.am without fixing the appropriate section in CMakeLists.txt right away then it was simply by mistake. Please, don't go on like this. Please don't start irritating _me_, as you irritated each and every other open source language implementor. I'm working my arse off for this fucking project, you know? This is the last warning. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] CMake problem on Linux should be solved
Brandon J. Van Every wrote: John Cowan wrote: _) | | __ \ | __| | / _ \ __ \ | | | | | ( < __/ | | \|_| |_|_|\___|_|\_\\___|_| _| It looks like CMake suddenly doesn't like the "\_" sequence in in the big-print "Chicken" output by "chicken-static -version", and then gets terminally confused after that. Ah, now I see the problem. The banner has changed the format for how it presents the version number. My regex is surely failing. Felix, it is hereby proven that you didn't touch or even look at CMake when doing your recent Autoconf changes. :-) I was serious about not chasing Autoconf, and not having things "dropped in my lap," especially right now with my financial situation. This one should be easy, but if you drop me something that's hard, I'm simply not going to do anything about it. And I'm going to get very, very irritated if you break things, in some kind of non-trivial manner, that I've been working hard to stabilize. I don't have any half-days to throw at CMake anymore; you will have to do them. So please consider design impacts on CMake. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
