Commit 89a3ca14 authored by Tiago de Freitas Pereira's avatar Tiago de Freitas Pereira

Trying to fix mac builds

parent f5a6d6a7
Pipeline #30228 failed with stages
in 134 minutes and 43 seconds
......@@ -132,11 +132,7 @@ test:
imports:
- {{ name }}
commands:
# fix for the CONDA_BUILD_SYSROOT variable missing at test time
- export SDKROOT="{{ SDKROOT }}" # [osx]
- export CONDA_BUILD_SYSROOT="{{ CONDA_BUILD_SYSROOT }}" # [osx]
- export MACOSX_DEPLOYMENT_TARGET="{{ MACOSX_DEPLOYMENT_TARGET }}" # [osx]
  • @tiago.pereira: if the environment variables are not set, I don't see how the test can eventually work.

    The way to fix this problem is the following, IMO:

    1. (Locally) Modify the line with nosetests to only execute the test that fails
    2. Using bdt build locally, build and test this package, see the test fail - the conda environment used is kept (use conda build purge to clean if you must)
    3. Without setting those variables explicitly like you did above, check first what are their values before the test executes by adding - echo VAR before the line that says nosetests ... in this conda recipe. Run bdt build and see the test fail again, but now check if the vars are set or not. Are they?
    4. If the variables are not carried out from the build (to be expected), then you'll need to set them in the recipe as per above. Those changes are fine, IMO - they are just capturing the build variables with the same name to the test phase -- makes sense.

    The second stage of the debugging is within the test that fails itself:

    1. Activate the build environment that failed (see instructions on conda build's log output), but this revolves around conda activate <path-to-workdir> (actually, I'm not sure this is required to run the next step...)
    2. Re-run the test script run_test.sh from the conda build workdir, on the activated environment if needs-be, and see it failing again.
    3. Verify again, that the environment variables above are correctly set just before the nosetests line.
    4. Now dive into the test itself. Print the value of the environment variables when the test start. Are those set? I expect that is the case. If not, then please report it here.
    5. If they are, then you know the problem is further down. Go moving the prints until close to the test failure point so you isolate the problem.

    Let me know of your conclusions.

Please register or sign in to reply
- nosetests --with-coverage --cover-package={{ name }} -sv {{ name }} --exclude=bob.extension.test_extensions --exclude=bob.extension.test_cmake:test_library
- nosetests --with-coverage --cover-package={{ name }} -sv {{ name }}
- sphinx-build -aEW {{ project_dir }}/doc {{ project_dir }}/sphinx
- sphinx-build -aEb doctest {{ project_dir }}/doc sphinx
- conda inspect linkages -p $PREFIX {{ name }} # [not win]
......
  • Just to keep track of the tests i'm doing. Locally I've tried to print the content of SDKROOT and MACOSX_DEPLOYMENT_TARGET before the bob nosetests

    Only the content of MACOSX_DEPLOYMENT_TARGET is properly printed.

    But the python test that checks if MACOSX_DEPLOYMENT_TARGET is set (os.environ.get('MACOSX_DEPLOYMENT_TARGET') fails. This variable is none at this time.

  • Another feedback.

    I've activated the environment that failed (with bdt build bob...), placed a breakpoint in ./bin/nosetests and checked the content of os.environ. The variables MACOSX_DEPLOYMENT_TARGET and SDKROOT are not there and I'm exporting them right before the line - nosetests -sv bob in the meta.yml.

    I have no idea what's going on

  • ignore it

    i was doing some s***t

  • Now I'm in the right track again.

    if i run nosetests -sv bob.extension.test_cmake:test_library the variables are there. Some test case is erasing these variables

  • I found a pattern that makes it fail.

    For instance, this run OK. nosetests --with-coverage --cover-package=bob -sv bob.extension

    BUT once you build bob.buildout together

    nosetests --with-coverage --cover-package=bob -sv bob.buildout bob.extension

    it fails (which means that os.environ does not have the variables we are expecting

  • mentioned in merge request bob.buildout!35 (merged)

    Toggle commit list
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment