Dima Kogan <[email protected]> writes:
> There are several other commits in that branch that do various useful
> things. They didn't seem significant enough to warrant their own
> branches and mailing list threads, so I'm bundling them with this
> email.
I took 7ccff524af2a8 (testsuite typos) and c4b9edd65b6 (whitespace
fixes) verbatim. Those are now on master.
bae1df98b (aliased symbol was breaking) looks OK, though that if (X)
return CBS_STOP; else return CBS_CONT; can be rewritten more concisely
as return CBS_STOP_IF (X). Let me know if you want to update it.
I appreciate the tests, this should help us keep the Dwarf part stable.
However I would like to see a C-only elementary test, possibly with
optional C++ part. C++ is not a hard dependency of ltrace. It is OK if
those parts use C++11, I understand that you need to test those parts of
Dwarf output. I'm however opposed to just enabling C++11 en bloc for
all C++ files. Personally, I'd prefer that you just change this:
[ltrace_compile_shlib $libsrc $lib_so debug ]
... to this:
[ltrace_compile_shlib $libsrc $lib_so
[list debug c++ additional_flags=-std=gnu++11]]
Though if you want to put the logic that just enables c++ in there like
you do in d983fbdf, that makes sense to me as well. In that case,
please update demangle.exp so that it doesn't list the c++ option
unnecessarily. But in any case, please keep the C++11 flags private to
your test case.
> Let me know if something is amiss. This is my first time writing (and
> reading, really) TCL, so maybe I messed something up, but it does appear
> to work.
TCL is an... interesting language. I'm afraid the ltrace test suite is
not the best TCL specimen out there. I added some support to simplify
writing tests some time ago (see e.g. parameters2.exp), but I'm no TCL
person myself, so who knows what someone knowledgeable would say.
Thanks,
PM
_______________________________________________
Ltrace-devel mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ltrace-devel
