Re: Heimdal 7.5.0: Some tests are run even if feature is disabled and test not possible
On Tue, 2019-01-08 at 13:20 +0100, Harald Barth wrote:
> I did configure with --disable-digest (I thought why would I need
> NTLM related stuff).
> Looks to me that the tests are not disabled when the feature is
I would caution from bad experiences in samba that making tests
optional risks missing the tests entirely.
We have found important tests were always skipped because the name
being tested for in the test code didn't match the name the build
system was using (we were doing a grep in config.h for HAVE_XXX).
So I'm just passing on a warning that such a feature is not risk-free.
When I build heimdal I normally have seperate source and build trees.
Then there are the files kadm5-protos.h kadm5-private.h which come
with the tar ball, live in source-tree/lib/kadm5, are obviously
generated and when other files in lib/kadm5 are touched are rebuild
with a perl script.
I very much dislike how this is done currently.
I suggest the following improvements:
* If one really feels the urge to distribute generated files with the
tar ball, do cp -p them over to the build tree.
* If you need to regen the files with a perl script, write only to the
* If the regen perl scripts fails, throw an error, don't just continue
with the make like nothing happened.
* If the regen perl script must have odd dependencies like libjson-perl,
somehow throw a reasonable error if that's not available.
Have a look at the cf/make-proto.pl it looks very unfinished to me.
* $Id$ should have a value or be removed
* A Copyright notice should be there
* Some better error handling than die "foo" would be nice
* I think this "Makefile obfuscation" does not work as
intened because if $(srcdir)/$$f is missing because
the perl step above failed, this will not be noticed.
for f in $$foo; do \
f=`basename $$f`; \
if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
else file="$$f"; fi; \
if cmp -s $$file $(buildkadm5include)/$$f 2> /dev/null ; then \
: ; else \
echo "cp $$file $(buildkadm5include)/$$f";\
cp $$file $(buildkadm5include)/$$f; \
fi ; \
I'd like to see that the build process of the kadmin stuff uses
kadm-protos.h from buildtree/include/kadm5/ and that gets built from
either the source files by make-proto.pl or if all the source files
are older from a distributed copy of kadm5-protos.h As it is now,
you can end up with a buildtree/include/kadm/kadm5-protos.h that is
inaccurate and/or older than soucretree/lib/kadm5/kadm5-protos.h.
I can not find any place where the make-proto.pl is used together with
the -x option. What is it supposed to do. Can you find what the -x
If the -x is not used, the JSON dependency can be removed completely.
If I sound a bit miffed this can be attributed to what I thought would
be a completely unrelated 10 min change/recompile/test cycle ended up
to be yak shaving galore expericence which took several hours. Don't
get me wrong, I know this is "free software" but I'm unhappy in the
same way one would not be happy if "free beer" would contain some
extra ingrediences which do not belong in beer in the first place ;-)
Re: Generated files in source tree: kadm5-protos.h kadm5-private.h
On 3/21/2019 6:45 AM, Harald Barth wrote:
> If I sound a bit miffed this can be attributed to what I thought would
> be a completely unrelated 10 min change/recompile/test cycle ended up
> to be yak shaving galore expericence which took several hours. Don't
> get me wrong, I know this is "free software" but I'm unhappy in the
> same way one would not be happy if "free beer" would contain some
> extra ingrediences which do not belong in beer in the first place ;-)
As a reminder, none of the active contributors to Heimdal work for
Heimdal. Those that are employed by AuriStor and Two Sigma work on
Heimdal in sprints. At least in the case of myself and AuriStor funded
developers, our work on Heimdal is primarily intended to satisfy the
requirements of AuriStor's internal use and its customers.
Over the months you have posted many requests for bug fixes and feature
changes to this mailing list. To increase the likelihood that someone
will review your request and do something about it, I suggest that you
submit it either as a GitHub Issue
During a future sprint I or other contributors can evaluate it, respond
to it and set a milestone if appropriate.
To be completely honest, I do not review the history of this mailing
list when I have time to work on Heimdal. There is already more than
enough queued in GitHub for the Heimdal 8 release. Please help us help
you by filing requests in GitHub. I for one do not have cycles to spare
to copy reports from this mailing list into GitHub.