On Wed, 3 Jun 2020 10:55:18 +0200 Quelrond <quelr...@gmail.com> said:
> Hello! > > > On 03/06/2020 09:47, Stefan Schmidt wrote: > > Hello > > > > On 02.06.20 19:10, Quelrond wrote: > >> Hi! > >> > >> Indeed, it is fixed now. > >> > >> Following the same logic, could it be possible to create Efl_One.h > >> file with ALL headers in the same file? > > > > I don't think this is a good idea. Let me explain why. > > > > First of all the _one_ suffix is really only used to indicate that its > > the merged libs and we need to have something as libefl.so is already > > used by a different project and can be on the system. > > > > Secondly it is a implementation detail if the libs are merged in one > > so or split on different ones. It should not be exposed to the header. > > You could not know what the system do when you write the application. > > > > I think what you are looking for is our push forward to a unified API. > > Which might at some point be able to include all you need when writing > > in application from one header file: Efl.h > > Probably, yes :) > > Hope, it will be here one day :) > > > > > >> It will be usable to create bindings for some languages. For example, > >> I tried to create Nim bindings, but their tool analyses headers and > >> EFL/Elementary headers have too complex structure, so it was failed. > > > > Sorry, but Efl_One.h header would not be the correct way to solve > > this. The complexity would be still there, as we would only include > > our existing headers into this one. > > > > If you can provide details on what is failing on their analyses of our > > headers we might be able to look into this. > > The way of creation C/C++ bindings in Nim is straightforward and simple > in case of presence of ONE header and ONE *.so library. There is a tool > that analyses the header and creates Nim file with functions/objects > that wrap C/C++ functions/objects. Then one just need to use that > wrapper and dynamically load the library and it's all done. In case of > including other headers from the first one (and presence of several *.so > files) the situation becomes much more complex. There are several tools > to work with such headers/libs, but they are all highly experimental and > don't work for any lib. So, I've just tried to use on of these tools to > analyze elementary.h - the tool was crashed, that's all :) So, probably > I'll wait for a better tool Nim side or for Efl.h EFL side ;) > > Personally, I like Nim very much and hope that one day EFL will be > available for Nim programmers. you wouldn't want that because efl includes #include system headers too and thus it would fool such a binding generator into generating bindings for libc functions too which it shouldn't. what you probably want is to have a look at how this nim binding generator works and then apply that to an eolian_gen binding generator that properly binds in basic data types (lists, stringshares, hashes, eina arrays etc.) as well and proper class hierarchies for eo classes, methods, properties, etc. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
