I must admit I had a "I'm not going to let this defeat me" moment this morning and learned enough about SCons to fix the SConstruct script. The first problem: There was no PATH at all in the environment, so no wonder it couldn't find the C compiler. Second problem: I built libz and installed it in a local directory, and the UNIX version of the SERF SConstruct didn't set ZLIB's include and lib into CPPPATH and LIBPATH. Third problem: expat was included as a library, which I again only installed locally, but EXPAT/lib wasn't included in LIBPATH. (In fact, there was no way to specify the directory for EXPAT.)
Mike S -----Original Message----- From: Stefan Sperling [mailto:s...@apache.org] Sent: Tuesday, August 22, 2017 3:20 PM To: Michael Schultz <michael.schu...@microfocus.com> Cc: Greg Stein <gst...@gmail.com>; dev@serf.apache.org Subject: Re: Please consider dropping scons On Tue, Aug 22, 2017 at 02:38:20PM +0000, Michael Schultz wrote: > Greg, > > Sadly, this is the sort of response that I expected. I had never heard > of SCons before running into this, and I never expect to run into it > again. I must admit that I must wonder if isn’t some sort of campaign > to force people to use something that the Serf developers consider a > superior solution, whether other people like it or not. Have you considered writing a Makefile which builds the C code on your platform and doesn't rely on external tools the platform lacks? That's still a lot of work but might be easier than building scons and all that entails. Ivan has already said that he does essentially the same on Windows and doesn't rely on scons. I would also prefer if serf used something other than scons but at this point it is water under the bridge. I was in a similar situation on OpenBSD where scons did not support building shared libraries correctly. I ended up sending patches to scons upstream to fix my problems.
