Factor out readtags as a standalone lib?

[raphinesse]

It would be great to have a standalone library to read tag files. As far as I understood, #63 is for generating tags, only.

[masatake]

My understanding is that you want libreadtags.so.

Sorry, but basically I don't want to maintain any library. I don't have enough skill and time for it.
However, as far as I know readtags.[ch] is stable enough. I recommend you to copy the files to anywhere you want.

About a tool you don't maintain, you can ask the maintainer of the tool to use readtags.[ch] of universal-ctags as I did in
universal-ctags/python-ctags3#8 .

[raphinesse]

My understanding is that you want libreadtags.so.

Not necessarily. That would be nice, but as you mention yourself, would also be an additional maintenance burden.

I was more thinking in the direction of pulling out the readtags code into its own repo. I seems just natural for a couple of reasons. It is differently licensed, is often depended on by other software and independent from the rest of the code AFAICT. Depending code would then be free to use git submodules to get up to date, if they choose so. Furthermore licensing issues would be clear (see #969).

[masatake]

Oh, I see... basically I agree with you. but I want more time about this. I added some experimental features to readtags command. I wonder which repository I should use for the rest source code.
I also think about build system and test facility.
Do you have time for working on separating readtags.[ch] from ctags as a member of universal-ctags organization?

For introducing new repository for readtags.[ch], we may have to do

1. make a repositry for readtags and put readtags.[ch] to the repository.
2. establish(?) the dependency from readtags command of ctags to the new repository.
   (git submodule may help up?)
3. update .travis.yml of ctags
4. advise readtags.[ch] repository to people who develops their own language biniding

I am overloaded. Someone asks me about release schedule. Yes, I should do concentrate on releasing a version. Highly improved parsers should be used widly. In other hand someone tells me too atractive ideas. This one is yet another one.

Fortunately about critically important parsers, we got great maintainers.
However, still the pool of developers is small.

About the license I would like to keep the policy which may be decided by Darren Hiebert in Exuberant-crags. I really don't want to change this area.

[raphinesse]

I will see what I can do and how much time I can take for this. My first step would be to take a closer look at the history of the readtags part. I will report back when there is progress.

[b4n]

I'm not sure a separate repository is a great idea. It could be if it's a truly standalone tool, but then the question arises: is it? Or do we want to be able to enhance it to match changes to ctags? If they are closely tied together however I'm afraid it will only make it harder to maintain it.

For licensing clarity we should probably improve the situation by stating that specific files' license clearly somewhere, but I don't think it requires a separate repository.

And regarding making it a library, it sounds like a good idea. I may be naive, but from my experience I wouldn't find maintaining a small library a large burden. Yes, it possibly requires a little more attention to potentially API or ABI breaking changes, but I feel fairly comfortable to that regard, and we can always bump SONAME too often if in doubt, it won't be worse than requiring applications to update the source code copy.
If it's something people want, I'd be willing to give it a look.
Disclaimer: I'm not knowledgeable about Windows, and there might be some extra weirdies there (dllimport/dllexport) I never properly grasped.

[raphinesse]

It could be if it's a truly standalone tool, but then the question arises: is it?

Isn't it?

Or do we want to be able to enhance it to match changes to ctags?

Don't we want to have a specified tag file format that producers as well as consumers then can adhere to?

[masatake]

I'm just talking about readtags.[ch]. I think they should not be enhanced any more. Obviously they are in maintenance mode. readtags-cmd.c and other files should be in ctags repository. Enhancement will go to the command side. Sexp based filtering I implemented is in dsl/*.[ch]. dsl/qualifier.c is GPLv2+.

(I will why I want to separate the repository later.)
What I expect the maintainer of readtags.[ch] will do are

1. integrating the build process of readtags command with the fetch readtags.[ch] from the new repository, and
2. advertising the repository to people who uses readtags.[ch] in one's project

The maintainer can do anything one's want. e.g. adding libreadtags.so target to the repository own Makefile. How ever I want the maintainer try to understand why Darren Hiebert uses GPL for ctags and "public domain" for readline.[ch] well.

Thought I want the separation, I myself don't because I don't want to take time for 1.

Next I write about the reason I want the separation.
When I talked to the maintainer of python-ctags3 (universal-ctags/python-ctags3#8), I recognized people utilizing readtags.[ch] in their tools want the upstream of readtags.[ch]. This is I have nerver thought of: I assumed people may just copy readtags.[ch] from .tar.gz or git repo of ctags to their source tree. Though I recognized it, but I didn't find what I could do for improving the situation.

The proposal from @raphinesse shows a direction: putting readtags.[ch] somewhere well visible place.

@raphinesse, my understanding is correct?

[raphinesse]

Yes, @masatake I would say that sums it up quite well. I already did some work by extracting the history of readtags from this repo. I don't know how much time I will be able to spend on the conversion, but I will report any progress here.