Daniel Stenberg wrote:
> I disagree about it being an abuse.
I'm actually surprised.
Compilers compile and build systems manage what files get compiled.
I hope you agree that the C preprocessor is not a build system.
> I rather defer all the build stuff on build other systems than my
> own to others
Yes and no. If a build system is to be supported by the project then
it should really include the complete range of functionality. This
isn't the case for *any* of the build systems in libssh2 besides
autotools. All others are hardcoded to OpenSSL.
> then I like being able to help them as much as possible and
I think it's important to consider what the project as a whole
outputs, rather than what individual contributors propose.
Discussions such as these can and often do lead to improvements,
but all improvements need time.
> using Makefile.inc for getting the files to build is one such way.
No way. It's really just nonsense.
> I vote for reverting d512b25f (although it doesn't do that cleanly
> right now)
At least you didn't do it already.
I guess you saw what I wrote about having implemented compatible
crypto library selection across nmake and automake only to discover
that nmake had never offered a choice in the first place?
So at this point I'm choosing between actually adding proper crypto
abstraction for nmake and keeping nmake hardcoded to use only
OpenSSL, and I think it would be quite stupid to accept that
OpenSSL is hardcoded for the native toolchain when we support
using the native crypto library.
Since the work to get rid of the hardcode is not blocking a flood
of commits at this instant perhaps you can embrace patience for a
bit longer, rather than rally for some action, any action,
immediately.
//Peter
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2013-09-18