On Mon, May 18, 2020 at 12:03 PM Marcel Hollerbach <[email protected]> wrote: > > Hi, > > I did not see this revision, as i was not getting a mail for that one. > > However, 2 benchmarks are build here with EFL_BUILD=1 which seems > absolut wrong with the description here.
no, they are not. They are needed because there are 2 imported header files, like Ecore_Data.h, which need that EAPI is correctly defined > Additionally, package_c_args can be used as a general "this is the > c_args" you should use during some declaration of buildstuff. > > That means, all this can simply be achived by ensuring every lib is > build with `c_args : package_c_args`. Before each call to subdir(*lib*) > you can add -DEFL_BUILD=1 to the package_c_args in root meson.build. And > before the call to subdir(*bin*) you could simply declare it to the > values they have now. > > Even more, there are currently only 9 users of package_c_args in the > binary folder, so i think just reevalulating these, and making them > package_bin_c_args is kind of easier than this here. > > The reason i am kind of against this change here is that we now do not > have a single variable that contains the c args the package needs. > Normally we should just concat custom things per package to that > variable, we then have a "model" like description of the library build > arguments and stuff like efl-one is way more easier. Parts of that > concatination are already in the efl-one patches that are in phab. > > Long story short: I dont think this is the right way of doing this. it is a way to fix the wrong definition of EAPI on Windows, which was wrong before. With the patch, it is fixed while modifying the meson.build, there are some of meson.build that have package_c_args while (and i don't know why) some don't. _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
