1. main@lists.aswf.io
  2. Messages
   Date   
Re: ASWF CI Infrastructure: VFX Reference Platform Dependencies

Daniel Heckenberg
 


Thanks for those of you answered the poll.  There's definitely enough interest to kick off the working group.

As you all probably realised, I made an error in my mental timezone juggling between Australian DST, US PDT and EDT (what's 2000 miles and 4 hours?!) so I've updated the poll to the correct time (same as the fortnightly TAC, but offset on alternate weeks) as originally planned.  A meeting invite and calendar update will come through on the TAC list shortly.

Thanks,
Daniel
Re: OpenVDB Jenkins builds broken due to Boost Python not found

Dan Bailey
 

Looking at the version of Boost that's being pulled in (1.58), that's actually older than the the version being specified by VFX Reference Platform for 2017 which is 1.61 (https://www.vfxplatform.com/).

I think we should ideally try and stick with the versions coming from the reference platform if possible rather than getting whatever is coming in with the Linux distro. More than likely this will mean a bit more work building from source and adding Boost headers/libraries for these specific versions into Nexus and pulling them down though. Likewise the compiler is GCC 5.4.0 which isn't the version specified by VFX Reference Platform.

I appreciate we're just trying to get things up and running in right now (and we don't even subscribe to this ideology in Travis for OpenVDB), so for expediency I think it makes sense to change CMake in whatever way is needed. Having said that, I would suggest that the Houdini plugins are probably a higher priority to figure out than the Python bindings as I believe most people are exposed to OpenVDB through Houdini these days.
Re: OpenVDB Jenkins builds broken due to Boost Python not found

Nick Porcino
 

Boost in general and boost python in particular complicates build environments, maintenance, and compiler migrations.

I would like to +1 the suggestion of a move to pybind11. This might be an excellent opportunity for community involvement.

- Nick
Re: ASWF CI Infrastructure: VFX Reference Platform Dependencies

Daniel Heckenberg
 


As discussed at the last TAC meeting, we'll set up a working group to progress this, and I'd like to encourage involvement from the community.

For pragmatic reasons, I'll propose the same timeslot as the TAC meeting, on alternate weeks.  That would place our first meeting on Wednesday 31 at 1pm (US/ EDT).  Please indicate your interest and ability to attend at this time in the following doodle poll:    https://doodle.com/poll/ig8zr6mtszq6r35p

Thanks,
Daniel
Re: OpenVDB Jenkins builds broken due to Boost Python not found

Daniel Heckenberg
 


It's never good to see a broken build, but in this case what serendipity!

It provides the perfect motivation for the cmake tools project which Larry has proposed on the tac mailing list, and demonstrates the kinds of ambiguities that we might reduce by defining a working set of vfxplatform builds to use as dependencies.

But back to the problem at hand... Can the OpenVDB folks address this, or should an issue be raised?

Thanks,
Daniel
Re: OpenVDB Jenkins builds broken due to Boost Python not found

Larry Gritz
 

Agreed about pybind11. I can't recommend it strongly enough.

Kimball did a good job of explaining what I was getting at, but I'll make a pitch on the TAC list in a new thread as well.

-- lg

On Oct 27, 2018, at 11:51 PM, Kimball Thurston <kthurston@...> wrote:

switch to pybind11? ;-P

This is what Larry was talking about the last meeting, and in a much more concrete manner than I had babbled about in our first meeting.

I think it is a great idea to make a repo that has template cmake macros and a collection of all the Find* things we need for the various projects in ASWF. People can then request those Find* be pushed upstream to cmake, and each project can keep a stash of what the current ones they need are, and rev versions as necessary to get whatever new macros, etc. they want.

Back to your actual question, in OpenEXR, we do a very similar thing to compile for a specific python variant, except don't have a period between when asking for boost:

.... <paraphrasing a bit here>

##### NB: with a period between maj.minor
find_package(PythonLibs ${OPENEXR_PYTHON_MAJOR}.${OPENEXR_PYTHON_MINOR}
##### NB: withOUT a period between
find_package(Boost COMPONENTS python${OPENEXR_PYTHON_MAJOR}${OPENEXR_PYTHON_MINOR})
if (NOT Boost_PYTHON${OPENEXR_PYTHON_MAJOR}${OPENEXR_PYTHON_MINOR}_FOUND)
   message(WARNING "requested boost python version not found...")
endif()
#####
find_package(NumPy)

....

Hope that helps,
Kimball
From: main@... <main@...> on behalf of Thanh Ha <thanh.ha@...>
Sent: Saturday, October 27, 2018 7:36:02 AM
To: main@...
Subject: [ASWF] OpenVDB Jenkins builds broken due to Boost Python not found
 
*Originates outside of Weta Digital


Hi Everyone,

Since the move of OpenVDB to ASWF. The Jenkins build is now broken due to CMake not able to find the python boost library, you can see the error message here:


I've traced it down to this commit which changed causing the build to now fail:


I'm not sure what Linux distro that patch was targetting but on Ubuntu 16.04 the boost python library is located in /usr/include/boost/python/ (with no trailing version number). I guess we need to improve the CMake script to detect if there is a trailing version or not. Does anyone else have any other recommendations on what we should do here?

Thanks,
Thanh


--
Larry Gritz
Re: OpenVDB Jenkins builds broken due to Boost Python not found

Kimball Thurston
 

switch to pybind11? ;-P


This is what Larry was talking about the last meeting, and in a much more concrete manner than I had babbled about in our first meeting.


I think it is a great idea to make a repo that has template cmake macros and a collection of all the Find* things we need for the various projects in ASWF. People can then request those Find* be pushed upstream to cmake, and each project can keep a stash of what the current ones they need are, and rev versions as necessary to get whatever new macros, etc. they want.


Back to your actual question, in OpenEXR, we do a very similar thing to compile for a specific python variant, except don't have a period between when asking for boost:


.... <paraphrasing a bit here>


##### NB: with a period between maj.minor

find_package(PythonLibs ${OPENEXR_PYTHON_MAJOR}.${OPENEXR_PYTHON_MINOR}

##### NB: withOUT a period between

find_package(Boost COMPONENTS python${OPENEXR_PYTHON_MAJOR}${OPENEXR_PYTHON_MINOR})

if (NOT Boost_PYTHON${OPENEXR_PYTHON_MAJOR}${OPENEXR_PYTHON_MINOR}_FOUND)

   message(WARNING "requested boost python version not found...")

endif()

#####

find_package(NumPy)


....


Hope that helps,

Kimball

From: main@... <main@...> on behalf of Thanh Ha <thanh.ha@...>
Sent: Saturday, October 27, 2018 7:36:02 AM
To: main@...
Subject: [ASWF] OpenVDB Jenkins builds broken due to Boost Python not found
 
*Originates outside of Weta Digital


Hi Everyone,

Since the move of OpenVDB to ASWF. The Jenkins build is now broken due to CMake not able to find the python boost library, you can see the error message here:


I've traced it down to this commit which changed causing the build to now fail:


I'm not sure what Linux distro that patch was targetting but on Ubuntu 16.04 the boost python library is located in /usr/include/boost/python/ (with no trailing version number). I guess we need to improve the CMake script to detect if there is a trailing version or not. Does anyone else have any other recommendations on what we should do here?

Thanks,
Thanh
OpenVDB Jenkins builds broken due to Boost Python not found

Thanh Ha
 

Hi Everyone,

Since the move of OpenVDB to ASWF. The Jenkins build is now broken due to CMake not able to find the python boost library, you can see the error message here:


I've traced it down to this commit which changed causing the build to now fail:


I'm not sure what Linux distro that patch was targetting but on Ubuntu 16.04 the boost python library is located in /usr/include/boost/python/ (with no trailing version number). I guess we need to improve the CMake script to detect if there is a trailing version or not. Does anyone else have any other recommendations on what we should do here?

Thanks,
Thanh
Re: ASWF CI Infrastructure: VFX Reference Platform Dependencies

Daniel Heckenberg
 


Hi Dan,

Thanks for the supportive feedback!

We have established vendor-approved mechanisms to automate download and build for the Maya SDK and for Houdini Apprentice which additionally allows for running tests.  The Foundry have indicated some support but that discussion is still in progress.

Some details, which I encourage others to correct to add to...

The Maya SDK (aka devkit) is directly downloadable. 

The Houdini download will require authentication but we plan to use Jenkins credential storage for an ASWF or OpenVDB project account.

Now that the OpenVDB project has been adopted and transferred into the ASWF we should be ready to start augmenting the CI with these components. 

Please lead the way, Dan!

Thanks,
Daniel



On Thu, Oct 25, 2018 at 7:08 AM +1100, "Dan Bailey" <danbailey@...> wrote:

Hi Daniel,

Thanks for sending this around, this is a great overview.

I know vendor dependencies were discussed in a past meeting, but skimming the meeting notes, I can't seem to find the outcome of those discussions. Wondering what the plan is to build against libraries for Houdini, Maya, Nuke, etc in terms of EULAs and exactly how this will be exposed in Nexus?

Regarding CI for OpenVDB specifically, I don't see a problem with sticking to using VFX Reference Platform versions of dependencies. I suggest one of the next steps will be to match the existing build matrix used with Travis CI (https://clicktime.symantec.com/a/1/7tI6fHsbeM79__DcOASJDJAxeOY9HSyVRbMO_nVOliw=?d=Z2KnFKxTJZI42zFyv8tNuxVINfbdxWtF1KYXk1uTmXGq5TQpUfofb9d4D1Dau_uJZXqQfItlx_E7xJkNFzXW9-yxC8vJXxyfGfW67po55JUlYT_BmgSKU1Yf8T6i6RBCGtakx_C6kkY3gELO2Ea1uOA14ioopLvHoXK62EvVszdo1qVYTvj145NNN5rXZTMmGdgxq06L7L_xH-jKsZh9lQlwVYglkArio_54CDTZeui2dxHx7C9Xaoj10Q0s4RAt5v622YA624-D1JV-WmSeDVb4gHo_DZOC5rbEkQvwI7nvMjwBRyrBKc4BqXzUFeDlgsBp266sjJ6tZchpP_lMRG5LElN-p9QRL3XAM0cWdK8pWT6zx-yh2f0No1EbhEeo-fVAGeuIF2_MzvFhKFWX3IRFyF9tvaFy-V7vK5ywYt-Z5TmfLXlbpFSC7RssBNA%3D&u=https%3A%2F%2Fgithub.com%2FAcademySoftwareFoundation%2Fopenvdb%2Fblob%2Fmaster%2F.travis.yml) and the major component missing in ASWF Jenkins currently is building the Houdini plugins. 

Thanks,
Dan
--
Daniel Heckenberg
R&D Supervisor - Graphics

T: +61 2 9383 4800 (main)
D: +61 2 8322 3123 (direct)
E: Daniel.Heckenberg@...

Building 54 / FSA #19, Fox Studios Australia, 38 Driver Avenue
Moore Park, NSW 2021
AUSTRALIA

  LinkedIn  Facebook  Twitter  Instagram

Animal Logic

www.animallogic.com

CONFIDENTIALITY AND PRIVILEGE NOTICE
This email is intended only to be read or used by the addressee. It is confidential and may contain privileged information. If you are not the intended recipient, any use, distribution, disclosure or copying of this email is strictly prohibited. Confidentiality and legal privilege attached to this communication are not waived or lost by reason of the mistaken delivery to you. If you have received this email in error, please delete it and notify us immediately by telephone or email.
Re: ASWF CI Infrastructure: VFX Reference Platform Dependencies

Dan Bailey
 

Hi Daniel,

Thanks for sending this around, this is a great overview.

I know vendor dependencies were discussed in a past meeting, but skimming the meeting notes, I can't seem to find the outcome of those discussions. Wondering what the plan is to build against libraries for Houdini, Maya, Nuke, etc in terms of EULAs and exactly how this will be exposed in Nexus?

Regarding CI for OpenVDB specifically, I don't see a problem with sticking to using VFX Reference Platform versions of dependencies. I suggest one of the next steps will be to match the existing build matrix used with Travis CI (https://github.com/AcademySoftwareFoundation/openvdb/blob/master/.travis.yml) and the major component missing in ASWF Jenkins currently is building the Houdini plugins. 

Thanks,
Dan
ASWF CI Infrastructure: VFX Reference Platform Dependencies

Daniel Heckenberg
 


Hello everyone,

As we start to adopt projects into the ASWF, I would like to turn attention to the CI setup and especially the way that project dependencies are built and managed.

There have been many discussions here and elsewhere which I shall ambitiously summarize as, "We should make the ASWF CI dependencies a practical realization of the VFX Reference Platform."   This would entail establishing build configurations for the relevant packages to be built from source and storage of the results as reusable artifacts.  As all parts of this chain will be open, accessible and reproducible this offers a great opportunity for contributions from the community, and for the configurations and artifacts to be used to facilitate software development and OSS software use.

Of course, there are lots of gaps and questions with this, such as "what do we do for non-Linux builds"?  I'd like to encourage the discussion here as we embark on the effort.

Some links follow with excellent Linux Foundation documentation of the CI infrastructure.

Thanks,
Daniel Heckenberg
ASWF TAC Chair

References: 
ci-management repo here:
CI docs are available here:
     https://docs.releng.linuxfoundation.org/en/latest/

As a background into the current ASWF CI infrastructure, Thanh Ha gave a great overview back in July:

CI Infrastructure Usage Details

Thanh Ha
Jul 31  

Hi Everyone,
 
The infrastructure for ASWF is ready to go and has the following components:
 
 
I will step through each of those components one by one below:
 
GitHub Organization
 
The current organization has 4 repos: ci-management, opencolorio, openexr, and openvdb.
 
The 3 project repos are just forks of their respective upstream projects. The "ci-management" repo contains the code for the CI system, mainly all of the Jenkins build scripts. It contains 3 important directories:
 
1. jenkins-config: contains Jenkins global configuration, usually not too important for contributors and is typically maintained by the releng team
2. jjb: contains the project build scripts, usually maintained by the releng team & projects
3. packer: contains the vm image build scripts, we try to make reproducible CI so that any org can take the same packer scripts and build the same VM Images in their own environments.
 
Projects typically will be most interested in the "JJB" directory and detailed documentation on Jenkins Job Builder (JJB) / Jenkins usage are available at these 2 links:
 
 
Jenkins Job Builder is a tool that allows projects to manage their Jenkins Job configuration using YAML configuration files typically stored in a Git repo so that it can be source controlled the same way as code.
 
When a Pull Request is merged in the ci-management repo a Jenkins job will kick off and automatically update all of the Jenkins jobs in the production system with the updated build configuration.
 
Jenkins / Jenkins Sandbox
 
We provide 2 Jenkins servers for projects to utilize the first is the production Jenkins system located at https://jenkins.aswf.io/ which is where all the production builds are run (the jobs that report back to GitHub). We do not allow developers to login and manage Jenkins in the production system, this is purely managed via the ci-management repo mentioned previously.
 
The 2nd system is the Jenkins Sandbox located at https://jenkins.aswf.io/sandbox is for projects to develop new job types and test their jobs before merging the patch into the ci-management repo and making it live to GitHub.
 
Detailed documentation on how to use the Jenkins Sandbox is available here:
 
 
Nexus
 
Sonatype Nexus located at https://nexus.aswf.io/ is where all of our build artifacts / binaries are released to. Typically a "staging" job will produce a staging repository in Nexus containing a Release Candidate build. Projects can then test this repository and once approved will be released to a "release" repository in Nexus to make it widely available.
 
Jenkins jobs typically manages the staging repository creation and LF Helpdesk will manage the release (we are working on some automation here for the future).
 
Jira
 
Jira located at http://jira.aswf.io/ can be used to track bugs and new feature development. We've created Jira projects for the 4 repo projects already ci-management, opencolorio, openexr, and openvdb.
 
Jenkins Jobs
 
With that said I'd like to discuss some Jenkins jobs we've rolled out already for the projects. For every project we have 2 job types "verify" and "stage".
 
The "verify" jobs are used to verify code contributions from contributors by running test build of the project. Typically it will also run any unit tests etc... as configured by the project for the build. This job also watches GitHub for keywords so if someone leaves a comment "recheck" in a PR comment the job will automatically retrigger for that PR. This is useful for rerunning the verify tests in case of intermittent issues.
 
As an example we've configured the OpenEXR project to run 2 verify builds for incoming PRs. One job runs autoconf build and the other job runs CMake build, this allows us to test both supported build methods simultaneously for all incoming PRs.
 
Example:
 
 
The "stage" job type produces release candidate builds. The idea is that this job can run periodically and a project can decide to release any particular day's "staged release" as the final release. The job stores a commit hash of the build so that the developer can tag the appropriate commit as was built by Jenkins after approving a staged release.
 
For example:
 
 
This job produced a staging repo "opencolorio-1002" here:
 
 
This is a temporary repository containing the artifacts for the release. Once a project decides to release this repo it will be copied to the final release repository here:
 
 
Making the artifacts in that staging repo available generally to the world.
 
This was a quick walkthrough of the current CI infra. It is a lot to cover all at once but please feel free to reach out with any questions about this system.
 


News Today: New Members & OpenVDB

Emily Olin
 

ASWF Community:

Today, the Academy Software Foundation announced four new members: Sony Pictures Entertainment/Sony Pictures Imageworks as a Premier member, Warner Bros. as a General Member, and Blender Foundation and Visual Effects Society (VES) as Associate members.
 
We also announced that OpenVDB, developed and maintained by DreamWorks Animation, has been approved as the Foundation's first hosted project.
 
The press release with additional details is here. Please consider sharing this news via your social channels. Below are some suggested Tweets.

Thanks!
 
.@SonyPictures @WarnerBrosEnt @Blender_Org and @VFXSociety join @AcademySWF! The Foundation also welcomes OpenVDB by @DWAnimation as its first hosted project. Read more here: https://bit.ly/2q8q13Q
Click-to-tweet: https://ctt.ac/jvd0t

.@AcademySWF gains momentum with four new members and approves OpenVDB by @DWAnimation as the Foundation's first open source project. Read more here: https://bit.ly/2q8q13Q

Click-to-Tweet: https://ctt.ac/0I86H

 
Re: hello

Cary Phillips
 


On Mon, Sep 24, 2018 at 10:55 AM <sreenivas9alapati@...> wrote:
Thanks for the answers Rob!
Cheers!



--
Cary Phillips | R&D Supervisor | ILM | San Francisco
Re: hello

sreenivas
 

Thanks for the answers Rob!
Cheers!
Re: hello

Rob Bredow
 


Thank you for your interest. Great questions.

1) No, or at least not yet. The VES is doing an excellent job running the VFX Platform and there are a number of other projects that the group has discussed which seem much higher priority to be adopted by the ASWF. Projects like OpenEXR, OpenVDB, OCIO are under active discussion for early adoption. That said, there is a lot of overlap between VES Technology Committee members and ASWF members and the door is open for any collaboration that makes sense for sure. But right now, I personally am just happy both projects are moving forward and staying in close communication with each other. For example, the build infrastructure is based heavily on compatibility with the VFX Platform.

2) Yes. I understand it's an open meeting. Only TAC members can vote, but the calls are open for anyone to join in. Take a look at the list here for meeting announcements.


Thanks--

Rob


On Mon, Sep 24, 2018 at 9:39 AM <sreenivas9alapati@...> wrote:
I am excited to seen the initiative by the community to push towards open source. Congratulations to all the folks involved in setting up ASWF!

Two questions I have! 
* Going forward, VFX platform(http://www.vfxplatform.com/) will be moved under the umbrella of ASWF ? 
* Are the Wednesday TAC meetings open for all to join ? 

Thanks!  

hello

sreenivas
 

I am excited to seen the initiative by the community to push towards open source. Congratulations to all the folks involved in setting up ASWF!

Two questions I have! 
* Going forward, VFX platform(http://www.vfxplatform.com/) will be moved under the umbrella of ASWF ? 
* Are the Wednesday TAC meetings open for all to join ? 

Thanks!  
Re: Building OpenEXR on Windows

Nick Porcino
 

Thanks! I was still grepping to find the VS2010 reference. The root Readme.md is correct.


On Wed, Sep 19, 2018 at 2:23 PM Cary Phillips <cary@...> wrote:
I'll update the README.

On Wed, Sep 19, 2018 at 12:57 PM Thanh Ha <thanh.ha@...> wrote:
Oh yeah that makes sense, I should have thought of that. I copied what was in README and didn't think to try changing the value. I got further now with the updated generator. Will report more on progress once I have something working.

Thanks,
Thanh

On Wed, Sep 19, 2018 at 3:40 PM Nick Porcino <nick.porcino@...> wrote:
Hi there, the script I see here: https://jenkins.aswf.io/sandbox/job/openexr-win64-master/configure seems to be incorrectly configured to run a very old Visual Studio, Visual Studio 2010.

-G "Visual Studio 10 Win64" ..

The Generator expression for CMake needs to specify version and year. We've tested OpenEXR with Visual Studio 2015 and 2017, and I see you're intending to use 2017. So, update the generator with:

-G "Visual Studio 15 2017 Win64"

HTH!

- Nick




On Wed, Sep 19, 2018 at 11:57 AM Thanh Ha <thanh.ha@...> wrote:
Hi Everyone,

We rolled out Windows builders for the ASWF project and are having some issues building OpenEXR's IlmBase project (see the command and error below) with it (trying to confirm that the builder is good). It seems like CMake is trying to call msbuild from a C:/Windows path but we have it installed at "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\msbuild"

It's not obvious to me where CMake is picking up this path. Is there a way I can tell it where to look for msbuild?

The jenkins job I've been tested is here:


Please let me know if the approach I am taking is incorrect, I'm trying to follow what's documented in the README.cmake.txt file.

Thanks,
Thanh


& "C:\Program Files\CMake\Bin\cmake" -DCMAKE_INSTALL_PREFIX=C:\lib\ilmbase -G "Visual Studio 10 Win64" ..

CMake Error at CMakeLists.txt:8 (PROJECT):
  Failed to run MSBuild command:

    C:/Windows/Microsoft.NET/Framework/v4.0.30319/MSBuild.exe

  to get the value of VCTargetsPath:

    Microsoft (R) Build Engine version 4.6.1586.0
    [Microsoft .NET Framework, version 4.0.30319.42000]
    Copyright (C) Microsoft Corporation. All rights reserved.

    Build started 9/19/2018 12:45:34 AM.
    Project "C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj" on node 1 (default targets).
    C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj(14,2): error MSB4019: The imported project "C:\Microsoft.Cpp.Default.props" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
    Done Building Project "C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj" (default targets) -- FAILED.

    Build FAILED.

    "C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj" (default target) (1) ->
      C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj(14,2): error MSB4019: The imported project "C:\Microsoft.Cpp.Default.props" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

        0 Warning(s)
        1 Error(s)



--
--------------------------------
Nick Porcino @meshula
Virtual and augmented production, interactive applications, and robotics, since 1982



--
Cary Phillips | R&D Supervisor | ILM | San Francisco



--
--------------------------------
Nick Porcino @meshula
Virtual and augmented production, interactive applications, and robotics, since 1982
Re: Building OpenEXR on Windows

Cary Phillips
 

I'll update the README.


On Wed, Sep 19, 2018 at 12:57 PM Thanh Ha <thanh.ha@...> wrote:
Oh yeah that makes sense, I should have thought of that. I copied what was in README and didn't think to try changing the value. I got further now with the updated generator. Will report more on progress once I have something working.

Thanks,
Thanh

On Wed, Sep 19, 2018 at 3:40 PM Nick Porcino <nick.porcino@...> wrote:
Hi there, the script I see here: https://jenkins.aswf.io/sandbox/job/openexr-win64-master/configure seems to be incorrectly configured to run a very old Visual Studio, Visual Studio 2010.

-G "Visual Studio 10 Win64" ..

The Generator expression for CMake needs to specify version and year. We've tested OpenEXR with Visual Studio 2015 and 2017, and I see you're intending to use 2017. So, update the generator with:

-G "Visual Studio 15 2017 Win64"

HTH!

- Nick




On Wed, Sep 19, 2018 at 11:57 AM Thanh Ha <thanh.ha@...> wrote:
Hi Everyone,

We rolled out Windows builders for the ASWF project and are having some issues building OpenEXR's IlmBase project (see the command and error below) with it (trying to confirm that the builder is good). It seems like CMake is trying to call msbuild from a C:/Windows path but we have it installed at "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\msbuild"

It's not obvious to me where CMake is picking up this path. Is there a way I can tell it where to look for msbuild?

The jenkins job I've been tested is here:


Please let me know if the approach I am taking is incorrect, I'm trying to follow what's documented in the README.cmake.txt file.

Thanks,
Thanh


& "C:\Program Files\CMake\Bin\cmake" -DCMAKE_INSTALL_PREFIX=C:\lib\ilmbase -G "Visual Studio 10 Win64" ..

CMake Error at CMakeLists.txt:8 (PROJECT):
  Failed to run MSBuild command:

    C:/Windows/Microsoft.NET/Framework/v4.0.30319/MSBuild.exe

  to get the value of VCTargetsPath:

    Microsoft (R) Build Engine version 4.6.1586.0
    [Microsoft .NET Framework, version 4.0.30319.42000]
    Copyright (C) Microsoft Corporation. All rights reserved.

    Build started 9/19/2018 12:45:34 AM.
    Project "C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj" on node 1 (default targets).
    C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj(14,2): error MSB4019: The imported project "C:\Microsoft.Cpp.Default.props" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
    Done Building Project "C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj" (default targets) -- FAILED.

    Build FAILED.

    "C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj" (default target) (1) ->
      C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj(14,2): error MSB4019: The imported project "C:\Microsoft.Cpp.Default.props" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

        0 Warning(s)
        1 Error(s)



--
--------------------------------
Nick Porcino @meshula
Virtual and augmented production, interactive applications, and robotics, since 1982



--
Cary Phillips | R&D Supervisor | ILM | San Francisco
Re: Building OpenEXR on Windows

Thanh Ha
 

Oh yeah that makes sense, I should have thought of that. I copied what was in README and didn't think to try changing the value. I got further now with the updated generator. Will report more on progress once I have something working.

Thanks,
Thanh

On Wed, Sep 19, 2018 at 3:40 PM Nick Porcino <nick.porcino@...> wrote:
Hi there, the script I see here: https://jenkins.aswf.io/sandbox/job/openexr-win64-master/configure seems to be incorrectly configured to run a very old Visual Studio, Visual Studio 2010.

-G "Visual Studio 10 Win64" ..

The Generator expression for CMake needs to specify version and year. We've tested OpenEXR with Visual Studio 2015 and 2017, and I see you're intending to use 2017. So, update the generator with:

-G "Visual Studio 15 2017 Win64"

HTH!

- Nick




On Wed, Sep 19, 2018 at 11:57 AM Thanh Ha <thanh.ha@...> wrote:
Hi Everyone,

We rolled out Windows builders for the ASWF project and are having some issues building OpenEXR's IlmBase project (see the command and error below) with it (trying to confirm that the builder is good). It seems like CMake is trying to call msbuild from a C:/Windows path but we have it installed at "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\msbuild"

It's not obvious to me where CMake is picking up this path. Is there a way I can tell it where to look for msbuild?

The jenkins job I've been tested is here:


Please let me know if the approach I am taking is incorrect, I'm trying to follow what's documented in the README.cmake.txt file.

Thanks,
Thanh


& "C:\Program Files\CMake\Bin\cmake" -DCMAKE_INSTALL_PREFIX=C:\lib\ilmbase -G "Visual Studio 10 Win64" ..

CMake Error at CMakeLists.txt:8 (PROJECT):
  Failed to run MSBuild command:

    C:/Windows/Microsoft.NET/Framework/v4.0.30319/MSBuild.exe

  to get the value of VCTargetsPath:

    Microsoft (R) Build Engine version 4.6.1586.0
    [Microsoft .NET Framework, version 4.0.30319.42000]
    Copyright (C) Microsoft Corporation. All rights reserved.

    Build started 9/19/2018 12:45:34 AM.
    Project "C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj" on node 1 (default targets).
    C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj(14,2): error MSB4019: The imported project "C:\Microsoft.Cpp.Default.props" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
    Done Building Project "C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj" (default targets) -- FAILED.

    Build FAILED.

    "C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj" (default target) (1) ->
      C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj(14,2): error MSB4019: The imported project "C:\Microsoft.Cpp.Default.props" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

        0 Warning(s)
        1 Error(s)



--
--------------------------------
Nick Porcino @meshula
Virtual and augmented production, interactive applications, and robotics, since 1982
Re: Building OpenEXR on Windows

Nick Porcino
 

Hi there, the script I see here: https://jenkins.aswf.io/sandbox/job/openexr-win64-master/configure seems to be incorrectly configured to run a very old Visual Studio, Visual Studio 2010.

-G "Visual Studio 10 Win64" ..

The Generator expression for CMake needs to specify version and year. We've tested OpenEXR with Visual Studio 2015 and 2017, and I see you're intending to use 2017. So, update the generator with:

-G "Visual Studio 15 2017 Win64"

HTH!

- Nick




On Wed, Sep 19, 2018 at 11:57 AM Thanh Ha <thanh.ha@...> wrote:
Hi Everyone,

We rolled out Windows builders for the ASWF project and are having some issues building OpenEXR's IlmBase project (see the command and error below) with it (trying to confirm that the builder is good). It seems like CMake is trying to call msbuild from a C:/Windows path but we have it installed at "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\msbuild"

It's not obvious to me where CMake is picking up this path. Is there a way I can tell it where to look for msbuild?

The jenkins job I've been tested is here:


Please let me know if the approach I am taking is incorrect, I'm trying to follow what's documented in the README.cmake.txt file.

Thanks,
Thanh


& "C:\Program Files\CMake\Bin\cmake" -DCMAKE_INSTALL_PREFIX=C:\lib\ilmbase -G "Visual Studio 10 Win64" ..

CMake Error at CMakeLists.txt:8 (PROJECT):
  Failed to run MSBuild command:

    C:/Windows/Microsoft.NET/Framework/v4.0.30319/MSBuild.exe

  to get the value of VCTargetsPath:

    Microsoft (R) Build Engine version 4.6.1586.0
    [Microsoft .NET Framework, version 4.0.30319.42000]
    Copyright (C) Microsoft Corporation. All rights reserved.

    Build started 9/19/2018 12:45:34 AM.
    Project "C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj" on node 1 (default targets).
    C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj(14,2): error MSB4019: The imported project "C:\Microsoft.Cpp.Default.props" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
    Done Building Project "C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj" (default targets) -- FAILED.

    Build FAILED.

    "C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj" (default target) (1) ->
      C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj(14,2): error MSB4019: The imported project "C:\Microsoft.Cpp.Default.props" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

        0 Warning(s)
        1 Error(s)



--
--------------------------------
Nick Porcino @meshula
Virtual and augmented production, interactive applications, and robotics, since 1982
101 - 120 of 189