Serf cannot configure without openssl

[GoogleCodeExporter]

checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking how to run the C preprocessor... gcc -E
checking for a BSD-compatible install... /usr/bin/install -c
Configuring Serf...

configure: error: '--with-openssl requires a path to a directory'

Original issue reported on code.google.com by Uffe.Jak...@gmail.com on 16 Jul 2009 at 9:36

[GoogleCodeExporter]

We discussed this for a few minutes at OSCON, it sounded like we wanted OpenSSL 
to always be required, as 
none of us liked the experience of compiling Neon and forgetting to add SSL 
support.

Original comment by paul.que...@gmail.com on 21 Jul 2009 at 11:00

[GoogleCodeExporter]

Well, that's exactly my point - if Serf cannot do what you can with Neon then 
it is
difficult to threat Serf as a "simple" replacement for Neon...

Original comment by Uffe.Jak...@gmail.com on 22 Jul 2009 at 8:14

[GoogleCodeExporter]

Can't we add a --without-openssl flag to buildconf/configure? This way we keep 
the 
openssl requirement by default, but allow people to build without it if needed.

Original comment by lieven.govaerts@gmail.com on 23 Aug 2009 at 9:58

[GoogleCodeExporter]

I just attempted to compile and build both neon and serf on Solaris 9. 

For neon, the default is "SSL disabled" and the "configure-make-make install" 
process
worked fine. Well, I appreciate paul.querna's view regarding user experience - 
if
users opt for neon's default installation, they will need to recompile neon to 
add
SSL support, if required later. 

However, for serf, compilation failed with the message "We require OpenSSL; try
--with-openssl". Some users (like me) have no requirement whatsoever for SSL 
given
their environment setup and should not be forced to install openSSL. 

So, while serf has pleased one group of users  (those who didn't like neon-s 
default
of SSL disabled), it has frustrated another set of users (those who don't need 
SSL).

I agree with lieven.govaerts. A default of "SSL enabled" with an option like
--without-openssl will certainly please all users.

Original comment by gavin.sa...@gmail.com on 27 Aug 2009 at 4:38

[GoogleCodeExporter]

I think the right thing to do is require OpenSSL by default, but allow a 
builder to take extra action to disable it. That should please all parties: by 
default, you "get the right thing". But if you have no need of OpenSSL, then 
you can disable it.

We're going to switch to scons, so I'm going to label this as a task for that 
project.

Original comment by gstein on 13 Jul 2011 at 6:42

• Added labels: Type-Task, scons
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

That approach would be fine. Thx

Original comment by Uffe.Jak...@gmail.com on 13 Jul 2011 at 8:12

[GoogleCodeExporter]

Please don't switch from autotools!
This is the only suite that is capable of cross compile cross platform without 
extra dependencies.

It can also be used to cross compile to windows environment if required.

SCcons can be kept for windows only environment, but in order to support most 
strange old/new platform and integrate correctly with package management 
without extra dependencies requires autotools.

Also I don't think that using a different build system than subversion with 
more dependencies is something good.

I can help you if you like to update your autoconf/automake/libtool 
configuration to most recent.
I already done this for many projects such as opensc, openvpn, ntfs-3g, 
uswsuspend, ecryptfs-utils and more.

Once autotools is well organized properly it is very easy to maintain.

If you are willing I can help.

Original comment by alon.barlev@gmail.com on 5 Oct 2011 at 7:33

[GoogleCodeExporter]

bug#82, I attached rewrite of autotools build system, if you give it a try it 
would be great.

I created the framework to disable the openssl usage at build, but at source 
there is need to add some conditionals, but I could not find the right location.

Original comment by alon.barlev@gmail.com on 5 Oct 2011 at 4:15