Sébastien Arnaud wrote: > Yes, he did his homework on this one. Very thorough. Anyway, 0.4.27 > builds fine with the 2 patches Marko submitted, but somehow when I > try to compile from SVN I get a strange error related to sed. I am > posting the output in case anybody as any idea of what's going on (I > am sure it's something simple I am missing;): > > sed: illegal option -- d > usage: sed script [-Ean] [-i extension] [file ...] > sed [-an] [-i extension] [-e script] ... [-f script_file] ... > > Any hint grealy appreciated ;)
If it compiles with the 0.4.27 tarball (+patch) but it fails to compile from the SVN I bet it is because the autotools version.. It seems like it (libtool, I suppose) is using an incorrect switch for your sed version. It is not GNU sed, isn't it? > Also, I know this does not affect compilation, but just to make it > cleaner, it would nice to remove the -pthread CFLAG for Darwin, as > it does not need it > (http://developer.apple.com/documentation/Darwin/Reference/ManPages/man3/pthread.3.html). > I believe pthread were introduced in OS 10.2, which may have > required the CFLAG (did not verify), but 10.3 and 10.4 certainly > don't need it. So I propose the following patch to configure.in: Does it hurt? I mean, is it a problem for the compilation on MacOS 10.3 or greater? If not, I would leave it like that as a compilation work around for the older versions. Well, or maybe we could add a more specific rule to the switch in which we can choose if add it or not based on the version number. > While I am at it, here is also a patch to autogen.sh so that under > OS X it uses the gnu version of LIBTOOL & LIBTOOLIZE, since Apple > had a the good idea to use those names for other purposes :( Ouch, I didn't know it. I have committed a little fix for it. It is not the patch you have sent, but it is really similar. http://svn.0x50.org/change/73 It lets you define the environment variables to define LIBTOOL and LIBTOOLIZE, and we can keep the script platform independent. LIBTOOL=glibtool LIBTOOLIZE=glibtoolize ./autogen.sh >> I will try to take a look at it. Anyway, if someone has it running >> it in *BSD with kqueue(), please let me know how is it working. > > I would, but I am not sure how easy it is to install one of the *BSD on > my powerbook. I see that FreeBSD 6 RC1 has added again PPC support > which is nice, I may try it if I get bored ;) Otherwise it seems that > OpenBSD is the way to go, at least for PPC hardware, but not easy to > make it share nicely the HD apparently... I will try with www.freesbie.org :-) >> About the pre-release performance tests.. do you have some idea >> about how to approach it? > > Well, I had thought about it and I think that using a python script to > run various tests on a local or remote cherokee peer would be the way > to go. I would still want to use a benchmarking tool like ab or httperf > but simply grab their output, parse it and build a little table of the > data collected to output to the user. I imagine it would neat if the > result of the script could be posted via HTTP to the cherokee web site > in order to collect info on those basics test on various cherokee > installs. On a practical level I imagine that you could release a > public candidate when you are done with your work for a new release and > give 48-72 hours to people on the list to download it and run the quick > benchmark script to post the results back to you. This way it might > allow you to collect the stats you need to make sure performance did > not drop from one release to the next. Again those benchmarks would be > pretty synthetic, but we are just looking at the variation, not at > getting a true benchmark of cherokee each time. To compare the > benchmark collected, it would require though to grab additional info on > the computer that ran it (OS, proc, compilation options, etc..) but I > don't think that's anything difficult a good python script could do ;) > Who knows, I may even have sometime to work on a prototype... Maybe autobench is a good utility to do it. http://www.xenoclast.org/autobench/ We might use an script to set up the server, create a bunch of testing files and run autobench. The report plus the box spec could be a good way to measure the performance. I'm releasing 0.4.28 today. I want the next release focused on performance, so it is the perfect moment to implement your idea. > Finally, again on a different topic, I put quickly together a Portfile > for DarwinPorts on OS X. Would you mind quickly making sure the info > below is correct? (basically description, etc...). As you can see it is > downloading 0.4.27, which will not work on OS X, when do you think you > will release 0.4.28 with all the patches that got submitted in the past > few days? There are a lot more options to complete like variants and > stuff, but I thought this would be a good start and wanted to have your > approval on the textual content first and refine the Portfile once > 0.4.28 is out. Ey, it is grand! :-) Use the freshmeat description, it is updated: http://freshmeat.net/projects/cherokee/ -- Greetings, alo. _______________________________________________ Cherokee mailing list [email protected] http://www.alobbs.com/cgi-bin/mailman/listinfo/cherokee
