1. 24 6月, 2022 1 次提交
  2. 11 5月, 2021 1 次提交
  3. 21 2月, 2018 1 次提交
  4. 20 2月, 2018 3 次提交
    • O
      fix multibuild hash · 62fe1dc2
      Olli-Pekka Heinisuo 提交于
      62fe1dc2
    • O
      fix some PEP8 style issues in setup.py · 22d47861
      Olli-Pekka Heinisuo 提交于
      22d47861
    • N
      Build via setup.py proper using scikit-build (#58) · 86e87d7d
      native-api 提交于
      * Adjust build environment as per https://docs.opencv.org/3.1.0/d5/de5/tutorial_py_setup_in_windows.html and https://wiki.python.org/moin/WindowsCompilers#Which_Microsoft_Visual_C.2B-.2B-_compiler_to_use_with_a_specific_Python_version_.3F
      
      * The best practice is to only use requirements.txt for deployments, not for packaging
      
      * ignore PyCharm metadata
      
      * refactor to be more modular
      
      * the warnings are irrelevant in older versions
      
      * v110 toolset might introduce dependency on older runtime not likely to be present in newer systems, potentially breaking upgrade
      
      * build locally with scikit-build
      
      * adjust appveyor config to local build
      
      * cleanup
      
      * DLL load works without
      
      * fail appveyor build immediately when one job fails
      
      * * cmd doesn't expand globs
      * - diplication
      * - WinXP-related bits
      * pip erroneously considers cv2/ as installed package when in sourceroot
      * require CMake output entries to be found
      * 3.5+ uses different .pyd naming scheme
      * .pyd is placed differently in Linux
      * DLL is only in Windows
      
      * ignore temporary config files
      
      * Yet another .pyd naming convention in Py35 Linux.
      Screw checking.
      
      * Update setup.py file to flag compatibility with Python 2.7-3.4-3.5-3.6 (#57)
      
      # Conflicts:
      #	setup.py
      
      * Adjust build environment as per https://docs.opencv.org/3.1.0/d5/de5/tutorial_py_setup_in_windows.html and https://wiki.python.org/moin/WindowsCompilers#Which_Microsoft_Visual_C.2B-.2B-_compiler_to_use_with_a_specific_Python_version_.3F
      
      * The best practice is to only use requirements.txt for deployments, not for packaging
      
      * ignore PyCharm metadata
      
      * refactor to be more modular
      
      * the warnings are irrelevant in older versions
      
      * v110 toolset might introduce dependency on older runtime not likely to be present in newer systems, potentially breaking upgrade
      
      * build locally with scikit-build
      
      * adjust appveyor config to local build
      
      * cleanup
      
      * DLL load works without
      
      * fail appveyor build immediately when one job fails
      
      * * cmd doesn't expand globs
      * - diplication
      * - WinXP-related bits
      * pip erroneously considers cv2/ as installed package when in sourceroot
      * require CMake output entries to be found
      * 3.5+ uses different .pyd naming scheme
      * .pyd is placed differently in Linux
      * DLL is only in Windows
      
      * ignore temporary config files
      
      * fail fast on error
      
      * * custom build logic should be unneeded now, will uncomment as needed
      
      * use the latest upstream multibuild
      
      * enable tracing
      - more suspicious things
      
      * save some build time
      
      * these somehow cause "Server does not allow request for unadvertised object" for GitHub
      
      * Revert "use the latest upstream multibuild"
      
      This reverts commit 915ba421f97acebb3edcf55b5e46ea7aab8fea42.
      
      * Yet another .pyd naming convention in Py35 Linux.
      Screw checking.
      
      * Update setup.py file to flag compatibility with Python 2.7-3.4-3.5-3.6 (#57)
      
      # Conflicts:
      #	setup.py
      
      * add diagnostics
      
      * * Use upstream multubuild due to the forked one abusing prebuild as build
      
      * save some time
      
      * looks like clean_code() isn't required
      
      * * Don't make CMake try Ninja first
      * MacOS LAPACK on Travis is still broken
      
      * See build progress as it goes
      
      * update submodules on demand
      
      * fetch source in time for find_version.py
      
      * use custom docker image
      
      * use custom multibuild
      
      * bump submodule
      
      * Linux/OSX are supposed to build with Qt support
      
      * * make shallow copies to save on download time
      * manylinux git is an old version
      
      * * clean up redundant syntax
      * reformat codeas YML multiline with dedent
      
      * IPP IW broken in Linux
      
      * + ffmpeg patch
      
      * additional deps required due to multibuild bug
      
      * +cv2.data
      
      * Use upstream multibuild with monkey patch
      
      * don't do anything if upload not needed
      
      * filter out irrelevant debug output
      
      * * clean up unused scripts
      * inline the remaining standalone scripts
      
      * https://github.com/matthew-brett/multibuild/issues/106 fixed
      
      * * bump OpenCV version to 3.4.0
      
      * * https://github.com/opencv/opencv/pull/10011 is available in 3.4.0
      * allow for if the sourcetree is a submodule
      
      * * don't reinstall whatever happens to be preinstalled
      * re-add workaround for https://github.com/travis-ci/travis-ci/issues/9055
      
      * * rearrange custom CMake flags
      * -DWITH_GTK=OFF proved to be unneeded, gthread is among manylinux requirements
      
      * fix linux detection to work in 3.3+, too
      
      * fix data path for other OSes
      
      * don't do anything unless deployment is requested
      
      * use upstream ``devel`` multibuild
      
      * restore from backup after rebase
      
      * catch fetch error
      
      * use `devel` multibuild
      
      * comment not using --depth
      
      * remove redundant command after merge
      86e87d7d
  5. 03 9月, 2017 1 次提交
  6. 04 3月, 2017 1 次提交
  7. 07 8月, 2016 1 次提交