The latest build runs great on my machine but perhaps that is because I don't use home-brew within the execution search context of my main partition? Can others confirm this issue and either post console log excerpts or even better, how to fix itpeterl94 wrote:Hey Bruce,
Have you tried running the build on your machine? I had a conflict with the Qt I have installed and the one in the bundle (both were loaded). I've had this problem before, but I don't remember what I did to fix it.
On the surface, it sounds like a search/loader path issue so it uses the QT version in the bundle. With more details, I will do some googling to see what we can do to fix it.I totally agree that all CI builds should be unified into the main FreeCAD repo on master so the community as a whole can maintain the CI build configurations across platforms... We all have peaks and valleys in our work lives that the larger community could easily mitigate with simple pull requests as needed... If we want more Mac users on FreeCAD, the we must routinely provide up-to-date builds for the platform.peterl94 wrote: I would like to see this in master, but it would need to be merged with the linux travis.yml first. By doing this, we would have the env variable TRAVIS_OS_NAME that could be used to run different things depending on the os. It looks like we would need to run a shell script for at least the "before_install" step. If we exported a variable for each step, one script could do almost everything. For the deploy step, we could put condition: "$TRAVIS_OS_NAME = osx" in the on section.
Currently, the Mac OS X builds alone take 50 minutes. The Travis-CI team was nice enough to increase the timeout for my repo to 60 minutes and agreed to do the same for the FreeCAD official repo when needed but I suspect we would need a lot more than 60 minutes to build Linux, Windows and OS X.
I would be happy to take a stab at a unified config as @peterl94 described that would produce the OS X build and provide hooks for the Windows and Linux builds. The os-specifics should be limited to the before_install and before_deploy phases to install the platform-specific dependencies and produce a platform-specific deployment archive.
Unfortunately, yaml does not support #include/import out of the box... OS-specific includes in the .travis.yml would be the way to go (e.g. ./src/Tools/ci/travis/before_install-${TRAVIS_OS_NAME}.yml)... I am really surprised that the travis-ci team hasn't extended their use of yaml to support some sort of include capability given the diverse multi-os and build matrix support they offer... They recommend that complex build steps be factored out into scripts but then you loose the declarative benefit offered by the .travis.yml - IMHO os-specific scripts are less desirable because they are imperative, not declarative. If I were in charge of travis-ci, I would extend the yaml slightly to support includes and conditionals (e.g. where clauses) while maintaining the current declarative simplicity.
So we can either go more imperative with something like ./src/Tools/ci/travis/before_install-${TRAVIS_OS_NAME}.py or try to stay declarative by folding platform-specific conditionals into the .travis.yml... For now, I think the latter may be the way to go; something like this (assuming case statements are supported, if not, we can use if/then/else)...
Code: Select all
os:
-linux
-windows
-osx
language: cpp
git
depth: 800
before_install:
-case ${TRAVIS_OS_NAME} in
"linux")
<apt-gets>
export CMAKE_ARGS=???
;;
"windows")
<???>
export CMAKE_ARGS=???
;;
"osx")
<homebrew port installs>
export CMAKE_ARGS="-DFREECAD_USE_EXTERNAL_KDL=ON -DFREECAD_CREATE_MAC_APP=ON"
;;
*)
echo "Unsupported os ${TRAVIS_OS_NAME}
exit 1
esac
install:
mkdir build && cd build && cmake -DCMAKE_BUILD_TYPE=Release ${CMAKE_ARGS} ### CMAKE_ARGS exported during before_install
before_deploy:
deploy:
???? #### We might be well-suited to use a deploy script provider to tailor multi-platform behavior support. ./src/Tools/github-deploy.py
after_script:
'''Send notifications...'''
The travis config for OS X deploys automagically to github so this is completely doable. You need two things, one github requires that the release be tagged, hence the versioning logic I included in the travis config to produce the tag and two, skip_cleanup: true, otherwise travis can't find the build artifacts to deploy.sgrogan wrote: I think we will need to let Travis-CI create the release and upload the osx artifact then I will need to get the release artifact url and upload the win artifacts there. I'm doing incremental builds so there might be a timing issue.
I think we can set up Travis to only deploy when the push is tagged. That way we could get the CI stuff for every push and pull request too! I think this would be a killer feature.
I still have trouble parsing the JSON response using curl and powershell. So now I am still uploading the artifacts manually. I have some time off work coming up, so hopefully I can solve this. I think if we can get bazaar installed in the linux travis we may be able to trigger the Ubuntu PPA automatically too.
Thoughts?
Cheers,
Bruce
. Would really think I'm going crazy if @peterl94 hadn't had the same problem…