rename utf8proc.h?

[stevengj]

For #5 (see also #7).

This breaks source compatibility, but on the other hand it is essential if someone wants to install both utf8proc and libmojibake on the same machine.

I think we should keep the utf8proc_* API, though.

[staticfloat]

Agreed; we should change the filename, but keep the same API. This will allow other projects, if they want, to be able to control which library they use without making extensive changes to their sources. Additionally, if/once we merge back in to upstream, this will allow us to change only our #include lines, we don't have to change function names.

[StefanKarpinski]

To play devil's advocate, I wonder if we shouldn't include some of the code in src/support for UTF-8 processing and change the interface to whatever we prefer. We could provide a utf8proc compatibility layer.

[stevengj]

@StefanKarpinski, unless there is some pressing motivation to combine the two codebases, I would wait to see how the Public Software Group reacts to this fork before making extensive API changes. If they are very motivated to merge our changes back into the mainline utf8proc sometime in the next few months, the fork may be short-lived.

In any case, I this is somewhat separate from whether the header file needs to be renamed.

[StefanKarpinski]

Yes, I suppose that would be a good outcome.

[stevengj]

Of course, if we kept the new API additions reasonably separate, then it wouldn't be a big obstacle to merging. But I don't see a pressing need for this right now.

[StefanKarpinski]

Fair enough. We'll see how it pans out.