On Oct 5, 2012, at 2:02 AM, [email protected] wrote:
> On Oct 5, 2012, at 10:54 AM, Jeremy Huddleston Sequoia wrote:
>> Looks like you made a copy/paste-o for one of them:
>>
>> -void result_free(result_t *r) __attribute__ ((weak, alias
>> ("csvdb_free_result")));
>> -+void result_free(result_t *r);
>> ++void result_free(result_t *r) __attribute__ ((deprecated));
>
> Ooops, what's wrong with marking this one here also as deprecated?
It's redundant. The purpose of the line you are removing is to provide
backwards compatibility such that anyone linking against the library using
result_free() would get csvdb_free_result() instead. On darwin, you would need
to provide this symbol as:
void result_free(result_t *r) {
csvdb_free_result(r);
}
But since this is a new project in MacPorts and you don't care about backwards
binary compatibility, that's not needed, so I just removed the line and fixed
the header to use a weakref in addition to the deprecation.
> Was it already sufficient to do that in the 1st patch file? Should I have
> stayed with just removing the alias or should I modify it differently?
Your changes would present a message of deprecation at compile time if someone
used result_free, but the resulting executable would fail to link. I fixed
such that it the call to result_free() would be rewritten to csvdb_free_result
at compile time.
> (At least it does build fine for me here, as well as for the buildbot.)
Yeah, the project builds fine, but a client of the project using the deprecated
result_free() would fail. Hopefully my 3am explanation above is not too
incoherent.
--Jeremy
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
