Re: [reSIProcate] Build systems.
> Just to be clear, I'm not advocating autotools. If the resiprocate
> community is willing to change our code so that it supports more
> architectures and code in a way that is a little bit more platform
> agnostic, then we don't likely need autotools.
Ok, I like that plan. What sort of things do you have in mind. Mostly we
have done a good job of keeping it so that it compiles on many architectures
> I'm just worried about
> making dynamic libraries on many platforms. Perhaps this is quite
> simple and it won't be a problem.
It's true that we will no doubt need to change a few lines of the makefile
for each platform but that has been just as true with autotools
>
> As for the current system. We do not have an installable library.
> Sure, something gets installed, but woe to the application writer
> that is unaware of how reSIProcate was compiled, or what version of
> reSIProcate it is. Some ABI versioning and site-local customizations
> need to be installed too. (NOT config.h). :-)
So the idea of having a binary call to get the version number seems like
good idea. How about making it so that unless someone has very weird needs,
they all compile the library with the same options. If people compile the
library with the "use Fortran stack calling conventions" then try to link
without using this option, I have very little sympathy. This is just not a
real problem. If people install different .h file than the library files on
their machine, well, what do other software projects do with this. I suspect
that the answer is not much. If I use the .h file from openssl 1.1 and use
the library from 1.2, bad stuff happens. Most people don't seem to find this
a problem.
>
> We are close and it may well be that the fast-path to getting this is
> to expand our current build system. That would be great.
>
> I just worry that ABI versioning + dynamic libraries == 90% of what
> autotools will do.
I have no idea what you are talking about here.
> I think our problem with autotools is that nobody
> on the project at the time we bit it off was 'an expert'. I'm hoping
> we might have one today, hence my call to arms. :-)
Uh, hmm, I think we had several people that had spent many many hours
learning about it. The fact we "need an expert" seems like a good argument
that there is a problem. If the "expert" gets a branch that is all set up
right, well, glad to try it. I believe several of us read the autoconf book
cover to cover.
We set up a list of clear goals that we would meet with autotools before
switching to it. I still think we have never meant theses goals and that we
should before switching.
>
> I just want a product we can package and have other applications use
> if it's installed on a system.
Ok - that is a good goal. What are the problems in doing this today. If the
issue is that some people compile the library with foo-buffer-size=64 and
the applications needs to be compile the same, well, lets remove these
options. I will point out that a ton of other libraries make two version,
one with ssl and one without. My vote would be make just one version and
have it use ssl.
>
> Detailed requirements for the build system will hopefully fall out of
> this discussion -- I am aware that once upon a time we had a list of
> requirements for giving autotools the green light. We never made it
> that far, either through lack of effort or possibly ignorance or lack
> of familiarity on our part.
>
> Let's see where we are at today so we can start 'installing' our
> fantastic SIP stack.
agreed
>
> Alan