Decide what to do with the glib dependency.

[stump]

libsmf as it exists now uses glib. Some people consider this OK; some people consider this undesirable.

I'm currently in the OK camp. I am thinking of using it to simplify error handling, remove utility code, preserve the ability to redirect log output to an arbitrary function, and deal with potential libc mismatches (a mostly Windows-specific problem, but an insidious one) for the functions that currently return malloc()'d memory and expect the caller to free() it when finished with it. Though we could do that last part by just adding a function that wraps free().

Arguments against continuing to use glib are that we currently use fairly little of it, it wouldn't be too hard to reimplement the parts we use (though the log message handling would of course become incompatible with the glib logging system without extra hacks), and it's a somewhat heavy dependency to be dragging around in certain contexts.

I like glib and want to keep it and take further advantage of it in libsmf , but I could be convinced not to do this.

[diovudau]

To know what "further advantage" could be taken with glib and libsmf it probably would be good to know what the future plans of libsmf are and how glib would make things easier and what would be left out without glib.

[przemoc]

I noticed that libsmf is no longer maintained by trasz and found your repository just recently.

When I read your first commits after taking maintenance, commits that are about tightening glib dependency, I was quite sad. But thankfully there is this issue created already, so it seems like you haven't set your mind yet. Well, that's a good thing.

I think that glib dependency should be completely removed, making libsmf a standalone library.

[stump]

...yeah, looking at this with a fresher mindset, I now agree that the glib dep definitely should go away, despite what I did so far.

I should have some time to accomplish that later this week.

[stump]

glib has been removed in branch libsmf1. Sorry it took so long.

It's in a branch because the resulting changes in struct contents and runtime warning handling are technically an ABI break, so I bumped soname in the branch.

There are a couple other things I want to do as long as I am bumping soname, such as hiding the private fields of the structs behind an opaque pointer (so they can be freely changed later, if necessary, without bumping soname again), making sure only symbols that really should be exported are, and making sure all argument and return types are actually semantically sensible. Once those are done I'll merge the branch, and probably make a release too.

I'm leaving this open until I actually do the merge.

[przemoc]

Thanks for getting rid of g_* stuff. A few picky remarks (I skimmed it only partially now), though:

• branch name libsmf1 sounds more like: oh, 1, possibly some old stuff instead of new work,
• you simplified messaging/logging, removing the importance/level info from it.

I think it is good to gradate messages, because they're not all equally important.
I suggest changing smf_warn(const char *fmt, ...) to smf_msg(int level, const char *fmt, ...) and introducing enum for commonly used levels (descending importance order): CRITICAL, ERROR, WARNING, INFO, DEBUG. Then warning handler should be changed to message handler that would receive additionally the level information, obviously.

And I commend upcoming sorting out of internal members needless visibility with opaque pointers to avoid unnecessary ABI bumps in future.

As for the branch name, it's simply cryptic for others. I recommend using names describing the kind of work (like improvement, refactorization, changes requiring abi-bump, etc.) and intent (removing glib dependency, introducing opaque pointers, etc.). In this case something like abi-bump/no-glib-dep would be much more clear and later you could create abi-bump/internals-behind-opaque-ptrs on top of that branch. In the end you would merge sequentially these abi-bump/* branches.

[stump]

I actually called the branch that because, being someone who primarily uses Debian, that's what the binary package name there will become with the bump (even though someone else maintains said package), and I felt that made the name sufficiently meaningful.

Yes, removing message level probably wasn't a good idea. But ironing out things like that is part of why I didn't finalize anything yet. Message levels will be put back.

(Maybe there should be other issues to keep track of the things to do while we're bumping, since this is now off the original topic of this one.)

[realnc]

Any plans for libsmf 2.0 with the new ABI?

[jmaibaum]

Hello @stump , I've seen your effort in continuing libsmf, so thanks for this!

How is the current plan for a new release of this library, i.e. is there anything that's still blocking a new release?