so that third party bindings can make use of it, obviously

yep - and we need a standard way which is not a bash script

welcome back @cedric o/

eolian_aux which is currently under review (D7245) provides this.

Not what I am getting

Also, I believe you are wrong:

IS that so? That is interesting, because a potential change of implementation (i.e. potentially behavior of Eolian itself) should trigger re-generation of eo.* files (in order to account for the new behavior), and changed headers should rebuild the rest of it. At least that's how I see it, if Meson does not do it, we potentially have another problem at hand...

Honestly, I think we should drop autotools as soon as possible.

why not? i don't see any particular disadvantage to it, and at least it allows addition of new APIs and being able to run tests on them without triggering a full EFL rebuild every time (as eolian_gen itself is most likely not going to depend on it)

I had plans for more, but I wasn't able to abstract these APIs well enough to make it into a reusable piece that makes sense. So for now there's these (they will help shorten the docgen) and more will be added gradually as I figure them out (but I won't actually focus on the library anymore once it's merged, just add new APIs as they make sense)

Perfect. We can synchronize efforts later then.

I took a break from that to work on meson, eolian_aux (which will be used to move some of the core from the docgen) and some other things, but the code is all in my personal dev repo... I will try to get a proper repository set up early next week or maybe even during this weekend. If somebody wants to help with working on the doc generator or even provide feedback on the generated output, go ahead, it would be much appreciated.

I still don't think that this will actually solve any real problem, but feel free to go ahead if you think it'll help, the constructor system is unlikely to stay in long term anyway

You are strduping the name, then returning it as a const char * and not freeing it, which results in an obvious memory leak; what you should do is move the declaration of legacy_group_name into _append_group, then pass it as a pointer to _get_group_name and snprintf into it when legacy is being used, then return it as a pointer, then no memory allocation is necessary, like this:

the reason is to enforce consistent documentation format where brief documentation comes first, detailed description later, and the since tag last; there is no deeper technical decision behind this

huh, that makes sense though... since the generated files changed, so the reference files in tests no longer match; it's a false positive but needs to be fixed anyway

👍

this looks fine, thanks

When I talk of a mapping file, what I have in mind is something like D7085, but generalized, moved out of source code and not doing O(n) lookup for each alias (therefore using a hash table to do lookups instead)

Option 2b as suggested by Xavi could also help, I strongly suggest looking into implementing it that way and see if it solves the problem for you.

If we are to add any sort of temporary fix to support legacy API documentation better, I suggest it is not done in the Eolian library or .eo files, but rather in the legacy header generator, using some kind of non-invasive approach that can be easily phased out once we've dealt with legacy APIs (for example, some kind of mapping file that can be easily expanded and later removed); the thing is, legacy APIs within .eo files are a non-ideal situation that creates a fair amount of burden on Eolian/eo and will likely be moved out into header files sometime in near future, and then there would be no need for any such workaround, because the docs for legacy will be like they used to be in the past. I'm open to having a temporary solution/workaround but not one that goes directly against our future goals.

Here is the thing; we have new documentation for generated eo API, on dokuwiki. Therefore, for that, doxygen is considered deprecated, and the only reason Eolian generates any Doxygen documentation comments is to help IDEs and other tools with suggestions, it is not intended for actual documentation generation. I am aware of the situation with legacy APIs, which are unfortunately also currently generated using Eolian; however, there is an ongoing investigation on how to deal with legacy APIs and things will very likely change significantly in near future, so there is no need right now to add something like this which would only introduce more APIs to deal with legacy into Eolian, when the ultimate goal is to reduce the amount of legacy stuff in Eolian. So what we need to do will only become clear depending on what path we will take with handling legacy in the EFL, but it will be different from what we have now.

@since has nothing to do with it; the ]] token simply terminates a documentation block regardless of presence of @since. The code just has an extra check that if you do use @since, then ]] has to follow, to prevent using @since in the middle of a documentation block.

The generator rewrite is pretty much done btw, including refactored C# support. It will be announced and hopefully made into an official repository within a few days.

I said this before but I'm not at all happy with the constructor system as it is, so I don't think it's right to just keep extending it and make things even harder for generators. Right now things are difficult and don't map well to pretty much any OO language, on the other hand I'm not entirely sure how to deal with it either :/

yeah we could probably have that, can you create a ticket and assign it to me?

Not necessary. The docs don't care if the parens are balanced or not. Do you have a legitimate use case for this? If you do, show me, if not, it's another O(n) check in an inner loop that is called numerous times that will ultimately slow down everything. Additionally, the Unicode decoding is completely unnecessary to handle ASCII characters.

Grouping is a purely legacy Doxygen feature and I don't think it's right to introduce it into docs at all. The generated Doxygen comments in the API are not for actual documentation, but more for IDE hints etc. where the group name does not matter.

I'm not sure if I like this, because it means hardcoding things and the constant lookups (which are O(n) from the alias table) will slow down the entire Eolian. I don't think it's worth it to bother with correct doxygen grouping at all, because the dokuwiki based docs are the way to go and legacy will come down to how it's handled in the future, which is currently subject to investigation.

@segfaultxavi eolian does exactly the same check at compile-time that eo does at runtime: https://git.enlightenment.org/core/efl.git/tree/src/lib/eolian/database_validate.c#n802

because it's regular multi-class inheritance and it's how eo was designed? i mean, that's what this ticket is trying to point out

now looks good

this doesn't seem to delete decl.eo, remove that from tree too

AM_CONDITIONAL inside EFL_LIB_START_OPTIONAL would result in the
variables not being defined with Elua disabled.

fair enough.

maybe using clang and ld.lld would also be worth a try (lld should be even much faster than gold, and clang should also be at least a little bit faster)

As talked over previously, I will claim this task and integrate C# into the current documentation generator. Before that, I intend to rewrite the documentation generator using a simpler design, so that it will become easier to integrate C# and other languages into it.

That doesn't make it okay.

This will obviously cause issues when e.g. using an efl dll on Windows with visual studio toolchain

keep in mind that this is not portable, it's a GNU extension, so not sure if it's a good idea to use it in a public header

@simotek think you could get me the backtrace so that i can finally deal with this?

I think this is currently not easily solvable using autotools. Perhaps setting LD_LIBRARY_PATH at the points when executables are being run would do the thing, but I'd say this is something to be addressed with switching to Meson.

well, i tried looking into this but as things are right now it's unsolvable. I guess we'll need to decide 1) whether this needs a solution, considering all the eo files have new non-doxygen docs 2) what would be the best approach to making it solvable...

this will need feature work so i removed the tag, but it'll get done for 1.22