Re: [E-devel] [EGIT] [core/efl] master 01/01: Fix EAPI definition by defining EFL_BUILD for each built DLL
On Mon, 18 May 2020 13:43:19 +0200 Vincent Torri said: > On Mon, May 18, 2020 at 12:55 PM Carsten Haitzler > wrote: > > > > On Mon, 18 May 2020 12:02:45 +0200 Marcel Hollerbach said: > > > > it built for me - but yes. ci seems to not be happy. reverted it. back to > > "considering the patch" mode. > > what is wrong with ci ? > > for me it compiles AND work > > i've spent several hours on it > > fix it then that's why i merged it - it worked for me, but it seems it doesnt, so backing back a step to re-evaluate -- - 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
Re: [E-devel] Coverity Scan subscription confirmation
Hello. On 18.05.20 14:42, scan-admin--- via enlightenment-devel wrote: Hi enlightenment-devel@lists.sourceforge.net, Your email was added by ste...@datenfreihafen.org to receive software defect notifications from [1]Coverity Scan for the Enlightenment Foundation Libraries project. To confirm and activate these notifications, [2]click here. If you do not wish to receive these emails, you may safely ignore this message. Great, so it finally worked! This should ensure that we are seeing the Coverity reports when new issues are seen on our daily run. This should get people a chance to look at them more quickly. regards Stefan Schmidt ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Coverity Scan subscription confirmation
Hi enlightenment-devel@lists.sourceforge.net, Your email was added by ste...@datenfreihafen.org to receive software defect notifications from [1]Coverity Scan for the Enlightenment Foundation Libraries project. To confirm and activate these notifications, [2]click here. If you do not wish to receive these emails, you may safely ignore this message. References 1. https://u2389337.ct.sendgrid.net/ls/click?upn=nJaKvJSIH-2FPAfmty-2BK5tYpPklAc1eEA-2F1zfUjH6teEyDQdpn7YXOjXXLADLo68fgPeYf_mvpcOc8FOVNbImGRSJC5zHD-2FhpVE1eyBkS-2FwxVM20bAYoRluBZqz-2BflYwpXqPgd3vZzcs4dNMMxukS94mtZg2veuGlgxUV9LK9j2zlQDTbPCUzNq58uJ6gZlmppwUoOm4qGkTXUbTkgAeyoLx04bnxENwPLHhbmVmp53UsiWDu5KrmEWmKK5sxtQk4I3MtE9FrdFrRKPiae2nzFnT-2FGyHH8g8SM1N8A3eU2qFQ7SoeP91ZPAq-2ByMSkz0moN56-2FH-2B 2. https://u2389337.ct.sendgrid.net/ls/click?upn=nJaKvJSIH-2FPAfmty-2BK5tYpPklAc1eEA-2F1zfUjH6teEwKPNNrzEFiIgTetQBd7l2XNRXuId0h7XGpQqeQ5mgr8rLgmvJCS3V7qmw7wN7kkCZf3Pl4A7hZ7dHhEDJDo9xOwmRZQz8gDXqHX8Q-2BnyzxikF7Ze6e0SQ3Kk4ULWed4qVVjR-2BqUgnH8HR6QXWcmPmgx1wkrubwLdlyWBHduZbXkw-3D-3DxJyV_mvpcOc8FOVNbImGRSJC5zHD-2FhpVE1eyBkS-2FwxVM20bAYoRluBZqz-2BflYwpXqPgd3vZzcs4dNMMxukS94mtZg2veuGlgxUV9LK9j2zlQDTbN-2Fgx6qZlytrtuVWoMbSOlCqNuH2TlbZcjgqpP6XpWg0deneruCoC-2BDNYCgFgpa3GkKd4B5kObf8Yn9b0sg6RfDKN17XC3DElDE3OpTfzXwzFptBvcx61AS2so4mYFW90Da55ErLcNyVUG-2FODZfImO-2F ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/efl] master 01/01: Fix EAPI definition by defining EFL_BUILD for each built DLL
On Mon, May 18, 2020 at 12:55 PM Carsten Haitzler wrote: > > On Mon, 18 May 2020 12:02:45 +0200 Marcel Hollerbach said: > > it built for me - but yes. ci seems to not be happy. reverted it. back to > "considering the patch" mode. what is wrong with ci ? for me it compiles AND work i've spent several hours on it fix it then ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/efl] master 01/01: Fix EAPI definition by defining EFL_BUILD for each built DLL
On Mon, May 18, 2020 at 12:03 PM Marcel Hollerbach 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/efl] master 01/01: Fix EAPI definition by defining EFL_BUILD for each built DLL
On Mon, 18 May 2020 12:02:45 +0200 Marcel Hollerbach said: it built for me - but yes. ci seems to not be happy. reverted it. back to "considering the patch" mode. > 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. > > 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. > > greetings, > bu5hm4n > > On 5/18/20 10:58 AM, Vincent Torri wrote: > > raster pushed a commit to branch master. > > > > http://git.enlightenment.org/core/efl.git/commit/?id=3ade45cbc82bea1772c7ad1afb7e1ba5dd67d930 > > > > commit 3ade45cbc82bea1772c7ad1afb7e1ba5dd67d930 > > Author: Vincent Torri > > Date: Mon May 18 09:48:17 2020 +0100 > > > > Fix EAPI definition by defining EFL_BUILD for each built DLL > > > > Summary: EAPI must be defined to dllexport when building DLL, and to > > dllimport when using these DLL. To achieve this, define EFL_BUILD for each > > library and module, and set DLL_EXPORT unconditionally. Static library are > > and will be not supported Test Plan: compilation > > Reviewers: zmike, raster, jptiz > > > > Subscribers: cedric, #reviewers, #committers > > > > Tags: #efl > > > > Differential Revision: https://phab.enlightenment.org/D11834 > > --- > > meson.build | 3 +-- > > src/benchmarks/eina/meson.build | 2 +- > > src/benchmarks/elementary/meson.build | 1 + > > src/edje_external/elementary/meson.build| 2 +- > > src/edje_external/emotion/meson.build | 2 +- > > src/lib/ecore/meson.build | 4 +++- > > src/lib/ecore_audio/meson.build | 3 +++ > > src/lib/ecore_con/meson.build | 4 +++- > > src/lib/ecore_evas/meson.build | 2 ++ > > src/lib/ecore_file/meson.build | 2 ++ > > src/lib/ecore_imf/meson.build | 3 ++- > > src/lib/ecore_imf_evas/meson.build | 4 +++- > > src/lib/ecore_input/meson.build | 2 ++ > > src/lib/ecore_input_evas/ecore_input_evas.c | 4 ++-- > > src/lib/ecore_input_evas/meson.build| 2 ++ > > src/lib/ecore_ipc/meson.build | 3 +++ > > src/lib/ecore_sdl/meson.build | 4 +++- > > src/lib/ecore_win32/meson.build | 4 +++- > > src/lib/ector/meson.build | 3 +++ > > src/lib/edje/meson.build| 4 +++- > > src/lib/eet/meson.build | 3 +++ > > src/lib/efl/meson.build | 3 +++ > > src/lib/efreet/meson.build | 8 +--- > > src/lib/eina/meson.build| 3 +++ > > src/lib/eio/meson.build | 4 +++- > > src/lib/eldbus/meson.build | 3 +++ > > src/lib/elementary/Efl_Ui.h | 7 --- > > src/lib/elementary/meson.build | 6 ++ > > src/lib/elua/Elua.h | 16 > > src/lib/elua/cache.c| 4 ++-- > > src/lib/elua/io.c | 4 ++-- > > src/lib/elua/meson.build| 4 +++- > > src/lib/embryo/embryo_main.c| 2 ++ > > src/lib/embryo/embryo_private.h | 2 -- > > src/lib/embryo/embryo_str.c | 2 ++ > > src/lib/embryo/meson.build | 4 +++- > > src/lib/emile/meson.build | 3 +++ > >
Re: [E-devel] [EGIT] [core/efl] master 01/01: Fix EAPI definition by defining EFL_BUILD for each built DLL
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. 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. greetings, bu5hm4n On 5/18/20 10:58 AM, Vincent Torri wrote: raster pushed a commit to branch master. http://git.enlightenment.org/core/efl.git/commit/?id=3ade45cbc82bea1772c7ad1afb7e1ba5dd67d930 commit 3ade45cbc82bea1772c7ad1afb7e1ba5dd67d930 Author: Vincent Torri Date: Mon May 18 09:48:17 2020 +0100 Fix EAPI definition by defining EFL_BUILD for each built DLL Summary: EAPI must be defined to dllexport when building DLL, and to dllimport when using these DLL. To achieve this, define EFL_BUILD for each library and module, and set DLL_EXPORT unconditionally. Static library are and will be not supported Test Plan: compilation Reviewers: zmike, raster, jptiz Subscribers: cedric, #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D11834 --- meson.build | 3 +-- src/benchmarks/eina/meson.build | 2 +- src/benchmarks/elementary/meson.build | 1 + src/edje_external/elementary/meson.build| 2 +- src/edje_external/emotion/meson.build | 2 +- src/lib/ecore/meson.build | 4 +++- src/lib/ecore_audio/meson.build | 3 +++ src/lib/ecore_con/meson.build | 4 +++- src/lib/ecore_evas/meson.build | 2 ++ src/lib/ecore_file/meson.build | 2 ++ src/lib/ecore_imf/meson.build | 3 ++- src/lib/ecore_imf_evas/meson.build | 4 +++- src/lib/ecore_input/meson.build | 2 ++ src/lib/ecore_input_evas/ecore_input_evas.c | 4 ++-- src/lib/ecore_input_evas/meson.build| 2 ++ src/lib/ecore_ipc/meson.build | 3 +++ src/lib/ecore_sdl/meson.build | 4 +++- src/lib/ecore_win32/meson.build | 4 +++- src/lib/ector/meson.build | 3 +++ src/lib/edje/meson.build| 4 +++- src/lib/eet/meson.build | 3 +++ src/lib/efl/meson.build | 3 +++ src/lib/efreet/meson.build | 8 +--- src/lib/eina/meson.build| 3 +++ src/lib/eio/meson.build | 4 +++- src/lib/eldbus/meson.build | 3 +++ src/lib/elementary/Efl_Ui.h | 7 --- src/lib/elementary/meson.build | 6 ++ src/lib/elua/Elua.h | 16 src/lib/elua/cache.c| 4 ++-- src/lib/elua/io.c | 4 ++-- src/lib/elua/meson.build| 4 +++- src/lib/embryo/embryo_main.c| 2 ++ src/lib/embryo/embryo_private.h | 2 -- src/lib/embryo/embryo_str.c | 2 ++ src/lib/embryo/meson.build | 4 +++- src/lib/emile/meson.build | 3 +++ src/lib/emotion/meson.build | 6 +++--- src/lib/eo/meson.build | 7 ++- src/lib/eolian/meson.build | 4 +++- src/lib/ephysics/meson.build| 4 +++- src/lib/ethumb/meson.build | 4 +++- src/lib/ethumb_client/meson.build | 4 +++- src/lib/evas/meson.build| 5 -
