Re: [E-devel] elm on Windows and elm_main
On Wed, 10 Aug 2011, Carsten Haitzler (The Rasterman) wrote:
On Tue, 9 Aug 2011 10:17:09 +0200 (CEST) Vincent Torri vto...@univ-evry.fr
said:
hmm welll the EAPI was there so *IF* u build the app AS a .so (.dll) then
elementary quicklaunch can run it faster (skipping several link and setup
steps
that are pre-done). thats why its EAPI. but if u build an executable on linux
the EAPI is harmless and doesnt hurt
so what you are saying here is this:
on linux we can put EAPI in binaries without harm
on windows putting EAPI in a binary will cause the compile to fail? (as
opposed
to a dll)?
I say that EAPI, in a binary that includes an EFL, is defined as
__declspec(dllimport), that mean that the symbol is imported from a DLL.,
so in a program using elm:
#include Elementary.h
// EAPI is __declspec(dllimport)
EAPI int elm_main()
{ ***
}
so the linker searches for elm_main() into a DLL, which is obviously not
the case, hence an error.
Vincent
--
uberSVN's rich system and user administration capabilities and model
configuration take the hassle out of deploying and managing Subversion and
the tools developers use with it. Learn more about uberSVN and get a free
download at: http://p.sf.net/sfu/wandisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] elm on Windows and elm_main
On Wed, 10 Aug 2011 08:00:21 +0200 (CEST) Vincent Torri vto...@univ-evry.fr
said:
On Wed, 10 Aug 2011, Carsten Haitzler (The Rasterman) wrote:
On Tue, 9 Aug 2011 10:17:09 +0200 (CEST) Vincent Torri vto...@univ-evry.fr
said:
hmm welll the EAPI was there so *IF* u build the app AS a .so (.dll) then
elementary quicklaunch can run it faster (skipping several link and setup
steps that are pre-done). thats why its EAPI. but if u build an executable
on linux the EAPI is harmless and doesnt hurt
so what you are saying here is this:
on linux we can put EAPI in binaries without harm
on windows putting EAPI in a binary will cause the compile to fail? (as
opposed to a dll)?
I say that EAPI, in a binary that includes an EFL, is defined as
__declspec(dllimport), that mean that the symbol is imported from a DLL.,
so in a program using elm:
#include Elementary.h
// EAPI is __declspec(dllimport)
EAPI int elm_main()
{ ***
}
so the linker searches for elm_main() into a DLL, which is obviously not
the case, hence an error.
ok - on linux EAPI simply is this symbol is visible/exported and not hidden.
so we have a disagreement of usage. the idea is that with quicklaunch u COMPILE
as a dll and then elm_main is exported as a symbol. as a binary - it is
useless. in the case of building the dll - it should be what it is now. in the
case of a binary it should actually be do nothing here. ie empty. maybe we
need a new macro? like ELM_MAIN or such that does this? ie ifdef windows -
#define it to nothing, if anywherre else #define it to EAPI
--
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
--
uberSVN's rich system and user administration capabilities and model
configuration take the hassle out of deploying and managing Subversion and
the tools developers use with it. Learn more about uberSVN and get a free
download at: http://p.sf.net/sfu/wandisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] elm on Windows and elm_main
On Wed, 10 Aug 2011, Carsten Haitzler (The Rasterman) wrote:
On Wed, 10 Aug 2011 08:00:21 +0200 (CEST) Vincent Torri vto...@univ-evry.fr
said:
On Wed, 10 Aug 2011, Carsten Haitzler (The Rasterman) wrote:
On Tue, 9 Aug 2011 10:17:09 +0200 (CEST) Vincent Torri vto...@univ-evry.fr
said:
hmm welll the EAPI was there so *IF* u build the app AS a .so (.dll) then
elementary quicklaunch can run it faster (skipping several link and setup
steps that are pre-done). thats why its EAPI. but if u build an executable
on linux the EAPI is harmless and doesnt hurt
so what you are saying here is this:
on linux we can put EAPI in binaries without harm
on windows putting EAPI in a binary will cause the compile to fail? (as
opposed to a dll)?
I say that EAPI, in a binary that includes an EFL, is defined as
__declspec(dllimport), that mean that the symbol is imported from a DLL.,
so in a program using elm:
#include Elementary.h
// EAPI is __declspec(dllimport)
EAPI int elm_main()
{ ***
}
so the linker searches for elm_main() into a DLL, which is obviously not
the case, hence an error.
ok - on linux EAPI simply is this symbol is visible/exported and not hidden.
so we have a disagreement of usage. the idea is that with quicklaunch u
COMPILE
as a dll and then elm_main is exported as a symbol. as a binary - it is
useless. in the case of building the dll - it should be what it is now. in the
case of a binary it should actually be do nothing here. ie empty. maybe we
need a new macro? like ELM_MAIN or such that does this? ie ifdef windows -
#define it to nothing, if anywherre else #define it to EAPI
last time i tried, i didn't succeeded in making quicklaunch work on
Windows. I remember of something specific to linux. But i can't remember
exactly what.
if it is possible to have quicklaunch on Windows, then EAPI must be
__declspec(dllexport) so that the symbol is exported, otherwise (in non
quicklaunch mode) EAPI must be nothing.
ELM_MAIN is already used, that's why I proposed EAPI_MAIN. EAPI_ELM_MAIN
could be used too. But yes, having such macro defined as nothing on
Windows, and EAPI otherwise should be sufficient. And if, later,
that macro must be tuned if quicklaunch works on Windows, then it will
not modify the way elm_main() is declared, it will always be
EAPI_MAIN int elm_main() { ** }
Vincent
--
uberSVN's rich system and user administration capabilities and model
configuration take the hassle out of deploying and managing Subversion and
the tools developers use with it. Learn more about uberSVN and get a free
download at: http://p.sf.net/sfu/wandisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] elm on Windows and elm_main
On Wed, 10 Aug 2011 08:24:41 +0200 (CEST) Vincent Torri vto...@univ-evry.fr
said:
On Wed, 10 Aug 2011, Carsten Haitzler (The Rasterman) wrote:
On Wed, 10 Aug 2011 08:00:21 +0200 (CEST) Vincent Torri
vto...@univ-evry.fr said:
On Wed, 10 Aug 2011, Carsten Haitzler (The Rasterman) wrote:
On Tue, 9 Aug 2011 10:17:09 +0200 (CEST) Vincent Torri
vto...@univ-evry.fr said:
hmm welll the EAPI was there so *IF* u build the app AS a .so (.dll) then
elementary quicklaunch can run it faster (skipping several link and setup
steps that are pre-done). thats why its EAPI. but if u build an executable
on linux the EAPI is harmless and doesnt hurt
so what you are saying here is this:
on linux we can put EAPI in binaries without harm
on windows putting EAPI in a binary will cause the compile to fail? (as
opposed to a dll)?
I say that EAPI, in a binary that includes an EFL, is defined as
__declspec(dllimport), that mean that the symbol is imported from a DLL.,
so in a program using elm:
#include Elementary.h
// EAPI is __declspec(dllimport)
EAPI int elm_main()
{ ***
}
so the linker searches for elm_main() into a DLL, which is obviously not
the case, hence an error.
ok - on linux EAPI simply is this symbol is visible/exported and not
hidden.
so we have a disagreement of usage. the idea is that with quicklaunch u
COMPILE as a dll and then elm_main is exported as a symbol. as a binary -
it is useless. in the case of building the dll - it should be what it is
now. in the case of a binary it should actually be do nothing here. ie
empty. maybe we need a new macro? like ELM_MAIN or such that does this? ie
ifdef windows -
#define it to nothing, if anywherre else #define it to EAPI
last time i tried, i didn't succeeded in making quicklaunch work on
Windows. I remember of something specific to linux. But i can't remember
exactly what.
if it is possible to have quicklaunch on Windows, then EAPI must be
__declspec(dllexport) so that the symbol is exported, otherwise (in non
quicklaunch mode) EAPI must be nothing.
ELM_MAIN is already used, that's why I proposed EAPI_MAIN. EAPI_ELM_MAIN
could be used too. But yes, having such macro defined as nothing on
Windows, and EAPI otherwise should be sufficient. And if, later,
that macro must be tuned if quicklaunch works on Windows, then it will
not modify the way elm_main() is declared, it will always be
EAPI_MAIN int elm_main() { ** }
maybe EAPI_MAIN is best.
--
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
--
uberSVN's rich system and user administration capabilities and model
configuration take the hassle out of deploying and managing Subversion and
the tools developers use with it. Learn more about uberSVN and get a free
download at: http://p.sf.net/sfu/wandisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] elm on Windows and elm_main
On Tue, 9 Aug 2011, Vincent Torri wrote: Hey on unix, it seems that EAPI is needed before elm_main (to export that symbol). But on Windows, having EAPI means that elm_main() must be in a dll that is loaded at runtime, which is not the case. I don't know what is the best way to fix that, maybe defining an EAPI_MAIN that is EAPI on unix, and nothing on Windows, and using EAPI_MAIN before elm_main() for all programs using elm. other ideas are welcome. note that this should be fixed before the 1.1 release of the EFL, as I plan to also release the EFL on Windows + elementary. Vincent -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] elm on Windows and elm_main
On Tue, 9 Aug 2011 10:17:09 +0200 (CEST) Vincent Torri vto...@univ-evry.fr said: hmm welll the EAPI was there so *IF* u build the app AS a .so (.dll) then elementary quicklaunch can run it faster (skipping several link and setup steps that are pre-done). thats why its EAPI. but if u build an executable on linux the EAPI is harmless and doesnt hurt so what you are saying here is this: on linux we can put EAPI in binaries without harm on windows putting EAPI in a binary will cause the compile to fail? (as opposed to a dll)? Hey on unix, it seems that EAPI is needed before elm_main (to export that symbol). But on Windows, having EAPI means that elm_main() must be in a dll that is loaded at runtime, which is not the case. I don't know what is the best way to fix that, maybe defining an EAPI_MAIN that is EAPI on unix, and nothing on Windows, and using EAPI_MAIN before elm_main() for all programs using elm. other ideas are welcome. Vincent -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
