You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@corinthia.apache.org by "Dennis E. Hamilton" <de...@acm.org> on 2015/01/01 22:08:05 UTC
x86 Externals?
Just a quick clarification.
The externals folder in the source tree seems to be exclusively for obtaining x86 libraries, DLLs, and include files. These are exclusively for compiling native Windows x86 code, yes?
And is their only use as dependencies from the minizip and w3c-tidy-html5 in DocFormats/platform/3rdparty ?
Another question. The externals/README.txt file says that there are external/download/bin DLLs that need to be copied to the directory containing the compiled Corinthia binaries.
Is there any need for the .exe files that are also extracted to download/bin? Could they simply not be extracted?
Is it necessary to keep the includes from libxml in download/include/libxml/ instead of just download/include ? (This one's no problem, I'm just curious.)
RE: x86 Externals?
Posted by "Dennis E. Hamilton" <de...@acm.org>.
-- replying below to --
From: jan i [mailto:jani@apache.org]
Sent: Thursday, January 1, 2015 13:35
To: dev@corinthia.incubator.apache.org; Dennis Hamilton
Subject: Re: x86 Externals?
On 1 January 2015 at 22:08, Dennis E. Hamilton <de...@acm.org>
wrote:
[ ... ]
> Another question. The externals/README.txt file says that there are
> external/download/bin DLLs that need to be copied to the directory
> containing the compiled Corinthia binaries.
[ ... ]
> Is there any need for the .exe files that are also extracted to
> download/bin? Could they simply not be extracted?
>
We dont copy the exe files for the packages, only .lib, .h and .dll
<orcmid>
I am looking at the externals/README.txt file and its long list of
what to expect. So it is not current?
</orcmid>
> Is it necessary to keep the includes from libxml in
> download/include/libxml/ instead of just download/include ? (This one's no
> problem, I'm just curious.)
>
I think you need to rebuild your tree (cmake -G), seems as if you dont run
with the latest VC solution.
Download is only temporary, everything we need is copied to externals/lib
/include /bin
<orcmid>
I don't know what it means to rebuild my tree. I do not run Cmake.
I am looking for what is essential for an extract_downloads batch
file. I should have been more clear what I was asking clarification
of.
</orcmid>
rgds
jan I
Re: x86 Externals?
Posted by jan i <ja...@apache.org>.
On 1 January 2015 at 22:08, Dennis E. Hamilton <de...@acm.org>
wrote:
> Just a quick clarification.
>
> The externals folder in the source tree seems to be exclusively for
> obtaining x86 libraries, DLLs, and include files. These are exclusively
> for compiling native Windows x86 code, yes?
>
yes
>
> And is their only use as dependencies from the minizip and w3c-tidy-html5
> in DocFormats/platform/3rdparty ?
>
the zlib dll is. The rest is (as far as I know) used directly in the
application code.
I think iconv is only used to get W:H on images, needed for the rendering.
>
> Another question. The externals/README.txt file says that there are
> external/download/bin DLLs that need to be copied to the directory
> containing the compiled Corinthia binaries.
>
or somewhere included in PATH. I have my dll in a c:/cmd directory.
>
> Is there any need for the .exe files that are also extracted to
> download/bin? Could they simply not be extracted?
>
We dont copy the exe files for the packages, only .lib, .h and .dll
>
> Is it necessary to keep the includes from libxml in
> download/include/libxml/ instead of just download/include ? (This one's no
> problem, I'm just curious.)
>
I think you need to rebuild your tree (cmake -G), seems as if you dont run
with the latest VC solution.
Download is only temporary, everything we need is copied to externals/lib
/include /bin
rgds
jan I
RE: x86 Externals?
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Thanks for the clarification on dependencies.
I notice, in verifying the running of my extract_downloads.bat script that there are two sources of zlib1.dll. There is the one in zlib-128-dll.zip which is about 105kb (identified as version 1.2.8.0), and one in SDL2_image-devel-2.0.0-VC.zip lib/x86 that is about 121kb (and identified as version 1.2.8.0).
I'm doing the extractions in the same order as in extract_downloads.sh, so the zlib-128-dll version ends up in download/bin.
1. I wonder if there are other collisions and if any of them matter.
2. I also notice that there is license information that goes with the DLLs from SDL2_image. We are not extracting any of that. It might be useful to do simply as a formality.
- Dennis
-----Original Message-----
From: Peter Kelly [mailto:pmkelly@apache.org]
Sent: Thursday, January 1, 2015 22:32
To: dev@corinthia.incubator.apache.org
Subject: Re: x86 Externals?
> On 2 Jan 2015, at 4:08 am, Dennis E. Hamilton <de...@acm.org> wrote:
>
> Just a quick clarification.
>
> The externals folder in the source tree seems to be exclusively for obtaining x86 libraries, DLLs, and include files. These are exclusively for compiling native Windows x86 code, yes?
Yes. I’m not sure what the best way to handle support for both x86 or x64 is; something we need to figure out. Ideally it would be nice to have the capability to build both.
> And is their only use as dependencies from the minizip and w3c-tidy-html5 in DocFormats/platform/3rdparty ?
No; libxml is used by DFXML.c (the only file that uses it), and SDL/SDL_image is used by Win32.c and Linux.c. zlib is, however, used only by minizip.
> Another question. The externals/README.txt file says that there are external/download/bin DLLs that need to be copied to the directory containing the compiled Corinthia binaries.
>
> Is there any need for the .exe files that are also extracted to download/bin? Could they simply not be extracted?
No; the .exe files are not needed.
> Is it necessary to keep the includes from libxml in download/include/libxml/ instead of just download/include ? (This one's no problem, I'm just curious.)
Yes; all the .h files in that directory are of the form #include <libxml/filename.h>, the assumption that there will be a subdirectory “libxml” in one of the system include directories containing those files (this requirement comes from the libxml library, not DocFormats itself).
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
Re: x86 Externals?
Posted by Peter Kelly <pm...@apache.org>.
> On 2 Jan 2015, at 4:08 am, Dennis E. Hamilton <de...@acm.org> wrote:
>
> Just a quick clarification.
>
> The externals folder in the source tree seems to be exclusively for obtaining x86 libraries, DLLs, and include files. These are exclusively for compiling native Windows x86 code, yes?
Yes. I’m not sure what the best way to handle support for both x86 or x64 is; something we need to figure out. Ideally it would be nice to have the capability to build both.
> And is their only use as dependencies from the minizip and w3c-tidy-html5 in DocFormats/platform/3rdparty ?
No; libxml is used by DFXML.c (the only file that uses it), and SDL/SDL_image is used by Win32.c and Linux.c. zlib is, however, used only by minizip.
> Another question. The externals/README.txt file says that there are external/download/bin DLLs that need to be copied to the directory containing the compiled Corinthia binaries.
>
> Is there any need for the .exe files that are also extracted to download/bin? Could they simply not be extracted?
No; the .exe files are not needed.
> Is it necessary to keep the includes from libxml in download/include/libxml/ instead of just download/include ? (This one's no problem, I'm just curious.)
Yes; all the .h files in that directory are of the form #include <libxml/filename.h>, the assumption that there will be a subdirectory “libxml” in one of the system include directories containing those files (this requirement comes from the libxml library, not DocFormats itself).
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)