Automated build using vcpkg

classic Classic list List threaded Threaded
11 messages Options
mhoward mhoward
Reply | Threaded
Open this post in threaded view
|

Automated build using vcpkg

Hey I found this automated build process called vcpkg that already has OSG inside of it and I was trying to add support for osgearth, but I am running into an error I am not sure how to handle.

The project is located here: https://github.com/Microsoft/vcpkg
I think this would be a huge help for new people trying to get started if we could get this working.

The problem I am running into is the automated build of OSG uses this flag -DOSG_USE_UTF8_FILENAME=ON

What this ends up doing is enabling this code inside osg's fileutil.cpp (https://github.com/openscenegraph/OpenSceneGraph/blob/OpenSceneGraph-3.5.10/src/osgDB/FileUtils.cpp#L125)
#ifdef OSG_USE_UTF8_FILENAME
#define OSGDB_STRING_TO_FILENAME(s) osgDB::convertUTF8toUTF16(s)
#define OSGDB_FILENAME_TO_STRING(s) osgDB::convertUTF16toUTF8(s)
#define OSGDB_FILENAME_TEXT(x) L ## x
#define OSGDB_WINDOWS_FUNCT(x) x ## W
#define OSGDB_WINDOWS_FUNCT_STRING(x) #x "W"
typedef wchar_t filenamechar;
typedef std::wstring filenamestring;
#else
#define OSGDB_STRING_TO_FILENAME(s) s
#define OSGDB_FILENAME_TO_STRING(s) s
#define OSGDB_FILENAME_TEXT(x) x
#define OSGDB_WINDOWS_FUNCT(x) x ## A
#define OSGDB_WINDOWS_FUNCT_STRING(x) #x "A"
typedef char filenamechar;
typedef std::string filenamestring;
#endif

The problem is when I try to run the automated build for osgearth it fails inside osgearths fileutil on this line: (https://github.com/gwaldron/osgearth/blob/master/src/osgEarth/FileUtils.cpp#L330)

#ifdef OSG_USE_UTF8_FILENAME
    if( _wstat64( OSGDB_STRING_TO_FILENAME(path).c_str(), &stbuf ) == 0 )
#else
    if( stat64( path.c_str(), &stbuf ) == 0 )
#endif

It says its failing because OSGDB_STRING_TO_FILENAME is not found

I am a novice at C++ but from what I can gather it looks like since this define: OSGDB_STRING_TO_FILENAME is only defined inside of the source file of osg's fileutil this makes it so that the compiler cannot find it inside the include file when trying to build osgearth's fileutil.

So I am not sure how this line
#ifdef OSG_USE_UTF8_FILENAME
    if( _wstat64( OSGDB_STRING_TO_FILENAME(path).c_str(), &stbuf ) == 0 )

was ever supposed to work or maybe I am just doing something wrong beause I thought that when referencing another project you can only see whats in the header file of a class and not anything that is defined in the source file.

Any help would be greatly appreciated!
jasonbeverage jasonbeverage
Reply | Threaded
Open this post in threaded view
|

Re: Automated build using vcpkg

I'm definitely interested in vcpkg, I've looked at it a little before but didn't see OpenSceneGraph as a supported project.  Can you point me to that build so I can take a look at it?

It sounds like osgearth would have an issue even outside of vcpkg when building withDOSG_USE_UTF8_FILENAME turned on.  I'll see if I can fix that.

Jason


On Fri, Apr 13, 2018 at 1:05 AM mhoward [via osgEarth] <[hidden email]> wrote:
Hey I found this automated build process called vcpkg that already has OSG inside of it and I was trying to add support for osgearth, but I am running into an error I am not sure how to handle.

The project is located here: https://github.com/Microsoft/vcpkg
I think this would be a huge help for new people trying to get started if we could get this working.

The problem I am running into is the automated build of OSG uses this flag -DOSG_USE_UTF8_FILENAME=ON

What this ends up doing is enabling this code inside osg's fileutil.cpp (https://github.com/openscenegraph/OpenSceneGraph/blob/OpenSceneGraph-3.5.10/src/osgDB/FileUtils.cpp#L125)
#ifdef OSG_USE_UTF8_FILENAME
#define OSGDB_STRING_TO_FILENAME(s) osgDB::convertUTF8toUTF16(s)
#define OSGDB_FILENAME_TO_STRING(s) osgDB::convertUTF16toUTF8(s)
#define OSGDB_FILENAME_TEXT(x) L ## x
#define OSGDB_WINDOWS_FUNCT(x) x ## W
#define OSGDB_WINDOWS_FUNCT_STRING(x) #x "W"
typedef wchar_t filenamechar;
typedef std::wstring filenamestring;
#else
#define OSGDB_STRING_TO_FILENAME(s) s
#define OSGDB_FILENAME_TO_STRING(s) s
#define OSGDB_FILENAME_TEXT(x) x
#define OSGDB_WINDOWS_FUNCT(x) x ## A
#define OSGDB_WINDOWS_FUNCT_STRING(x) #x "A"
typedef char filenamechar;
typedef std::string filenamestring;
#endif

The problem is when I try to run the automated build for osgearth it fails inside osgearths fileutil on this line: (https://github.com/gwaldron/osgearth/blob/master/src/osgEarth/FileUtils.cpp#L330)

#ifdef OSG_USE_UTF8_FILENAME
    if( _wstat64( OSGDB_STRING_TO_FILENAME(path).c_str(), &stbuf ) == 0 )
#else
    if( stat64( path.c_str(), &stbuf ) == 0 )
#endif

It says its failing because OSGDB_STRING_TO_FILENAME is not found

I am a novice at C++ but from what I can gather it looks like since this define: OSGDB_STRING_TO_FILENAME is only defined inside of the source file of osg's fileutil this makes it so that the compiler cannot find it inside the include file when trying to build osgearth's fileutil.

So I am not sure how this line
#ifdef OSG_USE_UTF8_FILENAME
    if( _wstat64( OSGDB_STRING_TO_FILENAME(path).c_str(), &stbuf ) == 0 )

was ever supposed to work or maybe I am just doing something wrong beause I thought that when referencing another project you can only see whats in the header file of a class and not anything that is defined in the source file.

Any help would be greatly appreciated!



If you reply to this email, your message will be added to the discussion below:
http://forum.osgearth.org/Automated-build-using-vcpkg-tp7591776.html
To start a new topic under osgEarth, email [hidden email]
To unsubscribe from osgEarth, click here.
NAML
mhoward mhoward
Reply | Threaded
Open this post in threaded view
|

Re: Automated build using vcpkg

Im glad to hear you are interested and sorry I should have made it more clear this is more than likely a problem with just building osgearth against an osg with that flag set in cmake and nothing to do with vcpkg itself.

Here is the current port files I am working with though, once I get them building properly I will make a pull request on vcpkg.

https://gist.github.com/battleguard/c1f549a8c93c470785019de44f252830

Right now I am looking at seeing if vcpkg port file will accept this cmake command remove_definition (https://cmake.org/cmake/help/v3.0/command/remove_definitions.html) in order to get it building.
jasonbeverage jasonbeverage
Reply | Threaded
Open this post in threaded view
|

Re: Automated build using vcpkg

So who maintains vcpkg?  If you need to make changes to your build do you have to issue a PR to vcpkg and get it included?

On Fri, Apr 13, 2018 at 9:18 AM mhoward [via osgEarth] <[hidden email]> wrote:
Im glad to hear you are interested and sorry I should have made it more clear this is more than likely a problem with just building osgearth against an osg with that flag set in cmake and nothing to do with vcpkg itself.

Here is the current port files I am working with though, once I get them building properly I will make a pull request on vcpkg.

https://gist.github.com/battleguard/c1f549a8c93c470785019de44f252830



If you reply to this email, your message will be added to the discussion below:
To start a new topic under osgEarth, email [hidden email]
To unsubscribe from osgEarth, click here.
NAML
mhoward mhoward
Reply | Threaded
Open this post in threaded view
|

Re: Automated build using vcpkg

The github account is microsoft that it is hosted under so I would think some microsoft employees maintain it. Since its part of there opensourceprogram it looks like getting a pull request approved should be pretty simple.

https://github.com/Microsoft/vcpkg
jasonbeverage jasonbeverage
Reply | Threaded
Open this post in threaded view
|

Re: Automated build using vcpkg

I just pushed a fix to the osgearth master that fixes the build when you build with OSG_USE_UTF8_FILENAME.  I had to include those defines from FileUtils.cpp into our FileUtils.cpp as well.

Give it a shot now and see if you have better luck.

Keep us posted on where you're at with vcpkg support, it would be great to have support for osgearth in there.  You can give us a primer on what you did when you're finished :)

Jason

On Fri, Apr 13, 2018 at 9:44 AM mhoward [via osgEarth] <[hidden email]> wrote:
The github account is microsoft that it is hosted under so I would think some microsoft employees maintain it. Since its part of there opensourceprogram it looks like getting a pull request approved should be pretty simple.

https://github.com/Microsoft/vcpkg


If you reply to this email, your message will be added to the discussion below:
To start a new topic under osgEarth, email [hidden email]
To unsubscribe from osgEarth, click here.
NAML
mhoward mhoward
Reply | Threaded
Open this post in threaded view
|

Re: Automated build using vcpkg

I have created my first pass of the osgearth port for vcpkg.
https://github.com/Microsoft/vcpkg/pull/3257/commits/c54fb431e7f5abb2dd2b1479126954b8e85db973

Some problems though I am facing.
- plugins and executables have to be put into the tools directory for vcpkg but if i try to run one of the executables like osgearth_viewer it will fail unless i manually move them afterwards into the bin folder. This probably wont change because there design does not want executables inside the bin folder. So this mainly will affect people wanting to run tests.
- Also even after I move all the tool folders over to the bin and run an osgearth_viewer example such as
osgearth_viewer.exe ..\tests\annotations_flat.earth

I run into erros with it loading the proj.dll I think this is related to the proj.dll inside of the install bin is called proj_4_9.dll.

Here is the console output I get with OSGEARTH_NOTIFY_LEVEL=DEBUG

[osgEarth]  [SpatialReference] allocating new OCT Transform
[osgEarth] [GDAL] Unable to load PROJ.4 library (proj.dll), creation of OGRCoordinateTransformation failed. (error 6)

full log here: https://gist.github.com/battleguard/dde9a752b9ae9d9f6c380c25c33c4dc4

Jason I am not sure the best way I can show you this problem. You could download my forked branch or you could just copy my portfile.cmake and control file from the pull request and create an osgearth folder in the ports folder of vcpkg.
then you would need to just run the command .\vcpkg.exe install osgearth:x64-windows

Hopefully you can shed some light on my problem with using the gdal proj dll.
jasonbeverage jasonbeverage
Reply | Threaded
Open this post in threaded view
|

Re: Automated build using vcpkg

I'm out of my element dealing with vcpkg, but how is gdal getting pulled down and built against osgEarth?  Is there a build script or something somewhere that is being run for osgearth in vcpkg?  As long as osgearth is linked with gdal it'll use whatever proj dll gdal was linked against I believe.

On Fri, Apr 13, 2018 at 3:38 PM mhoward [via osgEarth] <[hidden email]> wrote:
I have created my first pass of the osgearth port for vcpkg.
https://github.com/Microsoft/vcpkg/pull/3257/commits/c54fb431e7f5abb2dd2b1479126954b8e85db973

Some problems though I am facing.
- plugins and executables have to be put into the tools directory for vcpkg but if i try to run one of the executables like osgearth_viewer it will fail unless i manually move them afterwards into the bin folder. This probably wont change because there design does not want executables inside the bin folder. So this mainly will affect people wanting to run tests.
- Also even after I move all the tool folders over to the bin and run an osgearth_viewer example such as
osgearth_viewer.exe ..\tests\annotations_flat.earth

I run into erros with it loading the proj.dll I think this is related to the proj.dll inside of the install bin is called proj_4_9.dll.

Here is the console output I get with OSGEARTH_NOTIFY_LEVEL=DEBUG

[osgEarth]  [SpatialReference] allocating new OCT Transform
[osgEarth] [GDAL] Unable to load PROJ.4 library (proj.dll), creation of OGRCoordinateTransformation failed. (error 6)

full log here: https://gist.github.com/battleguard/dde9a752b9ae9d9f6c380c25c33c4dc4




If you reply to this email, your message will be added to the discussion below:
To start a new topic under osgEarth, email [hidden email]
To unsubscribe from osgEarth, click here.
NAML
mhoward mhoward
Reply | Threaded
Open this post in threaded view
|

Re: Automated build using vcpkg

In reply to this post by mhoward
so it looks like the gdal thats installed with osg must not have everything I need so I was able to get the projection problems fixed by just manually installing gdal after finding this link. Ill see if I can figure out the problem with the vcpkg gdal install.

https://stackoverflow.com/questions/43206742/unable-to-load-proj-4-library?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa
mhoward mhoward
Reply | Threaded
Open this post in threaded view
|

Re: Automated build using vcpkg

This post was updated on .
In reply to this post by jasonbeverage
from what I can tell GDAL is linked in osgearth by cmake pointing it to the vcpkg install directory. Every package you install with vcpk gets installed to this directory so linking is made easy.

When creating a port you have to make a control file that specifies  everything your package depends on. Here is osg's control file
Source: osg
Version: 3.5.6-2
Description:  The OpenSceneGraph is an open source high performance 3D graphics toolkit.
Build-Depends: freetype, jasper, openexr, zlib, gdal, giflib, libjpeg-turbo, libpng, tiff

So as you can see it depends on gdal so it will pull down GDAL's port file and build that one. For osgearth we only depend on OSG and since osg depends on GDAL we also get GDAL.

Here are osgearth's cmakecaches from vcpkg automated build process if that helps.
https://gist.github.com/battleguard/bb4524b0623a696034300dc5fbf682b7 

I am not sure why osgearth is trying to load proj.dll instead of proj_4_9.dll since the proj.lib should have that specified. I am very much a novice to c++ compiling so I am not sure how to figure out where in the code it is trying to load proj.dll from.

edit. so I have got a callstack to the problem and a link here to the source in gdal. It looks like for some reason GDAL is loading the Proj dll based of some define statements and in this case it finds it to be proj.dll

here is the call stack to the problem
> gdal202.dll!GetProjLibraryName() Line 194 C++
  gdal202.dll!LoadProjLibrary_unlocked() Line 213 C++
  gdal202.dll!OCTProj4Normalize(const char * pszProj4Src) Line 350 C++
  gdal202.dll!OGRSpatialReference::importFromProj4(const char * pszProj4) Line 512 C++
  gdal202.dll!OSRImportFromProj4(OGRSpatialReferenceHS * hSRS, const char * pszProj4) Line 369 C++
  osgEarthd.dll!osgEarth::SpatialReference::createFromPROJ4(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & proj4, const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & name) Line 85 C++
  osgEarthd.dll!osgEarth::SpatialReference::create(const osgEarth::SpatialReference::Key & key) Line 212 C++
  osgEarthd.dll!osgEarth::Registry::getOrCreateSRS(const osgEarth::SpatialReference::Key & key) Line 313 C++
  osgEarthd.dll!osgEarth::SpatialReference::create(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & horiz, const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & vert) Line 170 C++
  osgEarthd.dll!osgEarth::Profile::getProfileTypeFromSRS(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & srs_string) Line 498 C++
  osgEarthUtild.dll!osgEarth::Util::TMS::TileMapReaderWriter::read(const osgEarth::Config & conf) Line 572 C++
  osgEarthUtild.dll!osgEarth::Util::TMS::TileMapReaderWriter::read(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & location, const osgDB::Options * options) Line 475 C++
  osgdb_osgearth_tmsd.dll!osgEarth::Drivers::TileMapService::TMSTileSource::initialize(const osgDB::Options * dbOptions) Line 118 C++
  osgEarthd.dll!osgEarth::TileSource::open(const unsigned int & openMode, const osgDB::Options * readOptions) Line 281 C++
  osgEarthd.dll!osgEarth::TerrainLayer::createAndOpenTileSource() Line 770 C++
  osgEarthd.dll!osgEarth::TerrainLayer::open() Line 372 C++
  osgEarthd.dll!osgEarth::ImageLayer::open() Line 360 C++
  osgEarthd.dll!osgEarth::Map::openLayer(osgEarth::Layer * layer) Line 530 C++
  osgEarthd.dll!osgEarth::Map::addLayer(osgEarth::Layer * layer) Line 322 C++
  osgdb_earthd.dll!`anonymous namespace'::addLayer(const osgEarth::Config & conf, osgEarth::Map * map) Line 342 C++
  osgdb_earthd.dll!osgEarth_osgearth::EarthFileSerializer2::deserialize(const osgEarth::Config & conf, const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & referrer) Line 474 C++
  osgdb_earthd.dll!ReaderWriterEarth::readNode(std::basic_istream<char,std::char_traits<char> > & in, const osgDB::Options * readOptions) Line 284 C++
  osgdb_earthd.dll!ReaderWriterEarth::readNode(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & fileName, const osgDB::Options * readOptions) Line 216 C++
  osg148-osgDBd.dll!osgDB::Registry::ReadNodeFunctor::doRead(osgDB::ReaderWriter & rw) Line 959 C++
  osg148-osgDBd.dll!osgDB::Registry::read(const osgDB::Registry::ReadFunctor & readFunctor) Line 1210 C++
  osg148-osgDBd.dll!osgDB::Registry::readImplementation(const osgDB::Registry::ReadFunctor & readFunctor, osgDB::Options::CacheHintOptions cacheHint) Line 1302 C++
  osg148-osgDBd.dll!osgDB::Registry::readNodeImplementation(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & fileName, const osgDB::Options * options) Line 1474 C++
  osg148-osgDBd.dll!osgDB::Registry::readNode(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & fileName, const osgDB::Options * options, bool buildKdTreeIfRequired) Line 239 C++
  osg148-osgDBd.dll!osgDB::readRefNodeFile(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & filename, const osgDB::Options * options) Line 130 C++
  osg148-osgDBd.dll!osgDB::readRefNodeFiles(osg::ArgumentParser & arguments, const osgDB::Options * options) Line 266 C++
  osg148-osgDBd.dll!osgDB::readNodeFiles(osg::ArgumentParser & arguments, const osgDB::Options * options) Line 83 C++
  osgEarthUtild.dll!osgEarth::Util::MapNodeHelper::load(osg::ArgumentParser & args, osgViewer::ViewerBase * viewer, osgEarth::Util::Controls::Container * userContainer, const osgDB::Options * readOptions) Line 273 C++
  osgEarthUtild.dll!osgEarth::Util::MapNodeHelper::load(osg::ArgumentParser & args, osgViewer::ViewerBase * viewer, osgEarth::Util::Controls::Container * userContainer) Line 70 C++
  osgearth_viewerd.exe!main(int argc, char * * argv) Line 79 C++
  [External Code]

line where proj.dll looks to be defined: https://github.com/OSGeo/gdal/blob/v2.2.2/gdal/ogr/ogrct.cpp#L91
line where gdal attempts to load library: https://github.com/OSGeo/gdal/blob/v2.2.2/gdal/ogr/ogrct.cpp#L200
line where osgearth call gdal to load library: https://github.com/gwaldron/osgearth/blob/master/src/osgEarth/SpatialReference.cpp#L80

I also was able to get it working by setting an envionment variable PROJSO to proj_4_9_d.dll which causes this line to work here in loading proj inside of gdal: https://github.com/OSGeo/gdal/blob/v2.2.2/gdal/ogr/ogrct.cpp#L195
plevy plevy
Reply | Threaded
Open this post in threaded view
|

Re: Automated build using vcpkg

mhoward,

I am having a problem with the osgearth vcpkg build failing.  It may be my error but before the osgearth port was accepted, I built osg 3.5.6 and then updated the portfile to osg master.  Have you tried to build against osg master?

The build fails here:
src\osgEarthSymbology\CMakeFiles\osgEarthSymbology.dir\TextSymbol.cpp.obj -LIBPATH:G:\osgearth_2017\vcpkg\buildtrees\osgearth\x64-windows-dbg\lib lib\osgEarthd.lib G:\osgearth_2017\vcpkg\installed\x64-windows\debug\lib\osgd.lib G:\osgearth_2017\vcpkg\installed\x64-windows\debug\lib\osgWidgetd.lib G:\osgearth_2017\vcpkg\installed\x64-windows\debug\lib\osgUtild.lib G:\osgearth_2017\vcpkg\installed\x64-windows\debug\lib\osgSimd.lib G:\osgearth_2017\vcpkg\installed\x64-windows\debug\lib\osgTerraind.lib G:\osgearth_2017\vcpkg\installed\x64-windows\debug\lib\osgDBd.lib G:\osgearth_2017\vcpkg\installed\x64-windows\debug\lib\osgFXd.lib G:\osgearth_2017\vcpkg\installed\x64-windows\debug\lib\osgViewerd.lib G:\osgearth_2017\vcpkg\installed\x64-windows\debug\lib\osgTextd.lib G:\osgearth_2017\vcpkg\installed\x64-windows\debug\lib\osgGAd.lib G:\osgearth_2017\vcpkg\installed\x64-windows\debug\lib\OpenThreadsd.lib G:\osgearth_2017\vcpkg\installed\x64-windows\debug\lib\geosd.lib opengl32.lib glu32.lib G:\osgearth_2017\vcpkg\installed\x64-windows\debug\lib\OpenThreadsd.lib ws2_32.lib winmm.lib wldap32.lib psapi.lib G:\osgearth_2017\vcpkg\installed\x64-windows\debug\lib\osgd.lib G:\osgearth_2017\vcpkg\installed\x64-windows\debug\lib\osgShadowd.lib G:\osgearth_2017\vcpkg\installed\x64-windows\debug\lib\libcurl.lib G:\osgearth_2017\vcpkg\installed\x64-windows\lib\gdal.lib G:\osgearth_2017\vcpkg\installed\x64-windows\debug\lib\osgManipulatord.lib G:\osgearth_2017\vcpkg\installed\x64-windows\debug\lib\osgUtild.lib G:\osgearth_2017\vcpkg\installed\x64-windows\debug\lib\osgSimd.lib G:\osgearth_2017\vcpkg\installed\x64-windows\debug\lib\osgTerraind.lib G:\osgearth_2017\vcpkg\installed\x64-windows\debug\lib\osgDBd.lib G:\osgearth_2017\vcpkg\installed\x64-windows\debug\lib\osgFXd.lib G:\osgearth_2017\vcpkg\installed\x64-windows\debug\lib\osgViewerd.lib G:\osgearth_2017\vcpkg\installed\x64-windows\debug\lib\osgTextd.lib G:\osgearth_2017\vcpkg\installed\x64-windows\debug\lib\osgGAd.lib G:\osgearth_2017\vcpkg\installed\x64-windows\debug\lib\OpenThreadsd.lib opengl32.lib glu32.lib G:\osgearth_2017\vcpkg\installed\x64-windows\debug\lib\OpenThreadsd.lib opengl32.lib glu32.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib 
   Creating library lib\osgEarthSymbologyd.lib and object lib\osgEarthSymbologyd.exp
ninja: build stopped: subcommand failed.

I forced release build only and it fails as well.  Is it possible to get more verbose info out of the build process?  I am not sure it failed building osgEarthSymbologyd.lib or some other parallel operation.  Any tips on how to debug these build problems would be helpful as we do not have any vcpkg experience but it looks very promising for those on VS2017.

Thank you for the initial portfile

--
Paul Levy

On Fri, Apr 13, 2018 at 4:44 PM mhoward [via osgEarth] <[hidden email]> wrote:
from what I can tell GDAL is linked in osgearth by cmake pointing it to the vcpkg install directory. Every package you install with vcpk gets installed to this directory so linking is made easy.

When creating a port you have to make a control file that specifies  everything your package depends on. Here is osg's control file
Source: osg
Version: 3.5.6-2
Description:  The OpenSceneGraph is an open source high performance 3D graphics toolkit.
Build-Depends: freetype, jasper, openexr, zlib, gdal, giflib, libjpeg-turbo, libpng, tiff

So as you can see it depends on gdal so it will pull down GDAL's port file and build that one. For osgearth we only depend on OSG and since osg depends on GDAL we also get GDAL.

Here are osgearth's cmakecaches from vcpkg automated build process if that helps.
https://gist.github.com/battleguard/bb4524b0623a696034300dc5fbf682b7 


If you reply to this email, your message will be added to the discussion below:
http://forum.osgearth.org/Automated-build-using-vcpkg-tp7591776p7591785.html
To start a new topic under osgEarth, email [hidden email]
To unsubscribe from osgEarth, click here.
NAML