libgpg-error: Replace syscfg

[Jörg Krause]

On Mo, 2016-03-21 at 10:11 +0100, Werner Koch wrote:
> On Sun, 20 Mar 2016 23:06, joerg.krause at embedded.rocks said:
> 
> > 
> > The current mechanism of running gen-posix-lock-obj on a remote
> > target
> > for unsupported architectures is not suitable for building libgpg-
> > error 
> > with Buildroot.
> I don't know what Buildroot is but in any case gen-posix-lock-obj is
> just an example and you can of course also come up with the required
> snippet by other means.  It usuallay depends only on -lc and
> -lpthread.

All the information gen-posix-lock-obj provides are available at
compile-time, so I do not see the necessity for a runtime tool to fetch
the same information.

> > 
> > I had a look on gen-posix-lock-obj and I am quite sure the logic
> > can be
> > put into gpg-error.h itself. All necessary information are
> > available at
> This would make it a part of the ABI which we do not want.

The current mechanism lets gen-posix-lock-obj generate a lock object
definition which is copied right into gpg-error.h before compilation.
It does not make any difference if the data are copied into gpg-error.h 
before compilation or generated by compilation. The result is the same.

> The whole
> point with syscfg is to guarantee a stable ABI of libgpg-error so
> that
> an internal change to libgpg-error does not introduce a long chain of
> required ABI changes to all software dependent on libgpg-error.

I understand! However, as I said, there is no difference in the end
between using gen-posix-lock-obj/syscfg/mkheader generating the lock
part of gpg-error.h and defining the lock object directly in gpg-
error.h. Both produces the same compilation unit.

> So, this is a one time effort for a new platform which I think is
> justified.  Recall that a new platform also requires updates
> config.{sub.guess} and more.

Yes, but there are gazillions of possible triplets, which has to be
added to libgpg-error before it can be compiled.

Best regards
Jörg Krause