Think its nice to support path searching for windows, however the issues this causes aren't obvious and take a long time to solve.

How about we disable for now, but put behind a variable "WIN32_USE_FIND_LIB" for eg, then we can easily enable if we want.

Win 7, MSVC 2015
Worked for me-

Anaconda's libs had a sneaky way of getting into the Cmake profile. Applying this patch took care of it.

Thanks!

Thanks, works great :) git apply did give a warning about trailing whitespace on line 236 (line 71 of the diff)

There are several things i don't like about particular implementation:

• It considers hardcoded locations as a WARNING, which is misleading.
• It has fair amount of duplicated code.

Ideas:

• Have a macro which we can invoke like:

macro(windows_find_package)
  if(WITH_WINDOWS_FIND_MODULES)
    find_package("${PACKAGE}")
  endif()
  if(NOT ${PACKAGE}_FOUND)
    use_hardcoded_locations_passed_to_the_macro()
  endif()
endmacro()

windows_find_package(OpenSubdiv
                                        INCLUDE_DIR "opensubdiv/include"
                                        LIBPATH "opensubdiv/lib"
                                        LIBRARIES "osdCPU.lib;osdGPU.lib")

• Simply set/append FOO_ROOT_DIR at the top so later on we can use find_package().

In D2078#50570, @Sergey Sharybin (sergey) wrote:

There are several things i don't like about particular implementation:

• It considers hardcoded locations as a WARNING, which is misleading.

It only considers them a warning if you enable the use of find_package and it doesn't locate it, in that case it falls back to hardcoded paths and warns the user (given it is likely this is not what they expected)

• It has fair amount of duplicated code.

I resolved some of the duplicated code by macro's

Ideas:

• Have a macro which we can invoke like:

macro(windows_find_package)
  if(WITH_WINDOWS_FIND_MODULES)
    find_package("${PACKAGE}")
  endif()
  if(NOT ${PACKAGE}_FOUND)
    use_hardcoded_locations_passed_to_the_macro()
  endif()
endmacro()

windows_find_package(OpenSubdiv
                                        INCLUDE_DIR "opensubdiv/include"
                                        LIBPATH "opensubdiv/lib"
                                        LIBRARIES "osdCPU.lib;osdGPU.lib")

• Simply set/append FOO_ROOT_DIR at the top so later on we can use find_package().

I'm not sure this can be generalized easily there's a lot of variation in naming of things by some of the find_xxxx scripts, INCLUDE_DIR vs INCLUDE_DIR , LIBRARY vs LIBRARIES , debug vs release libs, etc etc. While it sounds like a nice idea, it does sound like it'll require a lot more time than I have to spend right now. For now i'm just looking to get the people with anaconda installed (which seems to be the root cause of most lib errors now days) building successfully again.

Ah, you're right about warning only if the WITH_WINDOWS_FIND_MODULES is enabled.

But think we can still reduce amount of lines here:

macro(win_find_package NAME)
  if(WITH_WINDOWS_FIND_MODULES)
    find_package(NAME)
    if(NOT ${NAME_FOUND})
      message(WARNING "Package ${NAME} not found, will be using hardcoded locations")
    endif()
  endif()
endmacro()

Then we can only invoke the macro and skip adding if(WITH_WINDOWS_FIND_MODULES) all over the place.

How about that?

Then we can only invoke the macro and skip adding if(WITH_WINDOWS_FIND_MODULES) all over the place.

That's already gone, only place that still has it is the boost section cause it has a bunch of parameters i didn't know how to wrap.

How about that?

I kinda like them separated as is (find & warn). I hate for windows_find_package to all confidently go 'hardcoded paths will be used!' when there might not be actually code to back up that claim.