Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP Add recipe for cxxwrap #3925

Closed
wants to merge 2 commits into from

Conversation

SylvainCorlay
Copy link
Member

The CxxWrap package by @barche is to Julia what boost.python and pybind11 are to Python.

The goal of this PR is to explore how Julia native extensions can be packaged for conda (and other general-purpose package managers). It is now possible since Julia was packaged for conda-forge (cf #3503) thanks to the hard work of @dfornika, and others who worked on the massive PR (@bgruening, @tkelman, @acaprez).

This is work in progress, now only packaging the C++ part (jlcxx).

Ideally, I would like the conda package to differ from the julia package in that jlcxx would be installed in the general prefix instead of being vendored under the julia directory.

This poses two questions for CxxWrap:

  • should we add a flag (e.g. with an environment variable) to prevent the CxxWrap Julia package to vendor jlcxx headers.
  • should CxxWrap and jlcxx be two separate packages from a conda viewpoint?

Ping @barche.

@conda-forge-linter
Copy link

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipes/CxxWrap) and found it was in an excellent condition.

@SylvainCorlay
Copy link
Member Author

An approach that I am thinking of is to open a PR to the upstream CxxWrap repository, temporarily point to my fork in this PR, so that we can iterate on the changes to build.jl in the fork.

@barche
Copy link

barche commented Sep 9, 2017

Sure, support for a separate jlcxx binary should be doable. We would need a way for the CxxWrap Julia package to check that the binary is compatible with the Julia side, though (i.e. a kind of versioning scheme).

@SylvainCorlay
Copy link
Member Author

I guess I will keep jlcxx and cxxwrap together in a single package for now. From what we learn in doing that, we might want to separate things later.

if errorlevel 1 exit 1

nmake install
if errorlevel 1 exit 1
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it make sense to even include this yet if we are not building on Windows?

@jakirkham
Copy link
Member

Could also split them and provide a metpackage that pulls in both components.

@SylvainCorlay
Copy link
Member Author

I think that eventually it should build on windows. I am testing with a local windows install of julia.

@jakirkham
Copy link
Member

Opened issue ( conda-forge/julia-feedstock#14 ) to discuss how we want to handle Julia packages with conda. Would love for people interested in this PR and adding other Julia packages to conda-forge to join in the discussion.

@jakirkham
Copy link
Member

Should add that Julia seems to place packages in a directory that specifies the major minor version of Julia used. So we might need matrix builds or something like this.

@SylvainCorlay
Copy link
Member Author

Closing now that CxxWrap was successfully split into a pure C++ package and a Julia package.

@SylvainCorlay SylvainCorlay deleted the cxxwrap branch May 21, 2018 14:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

4 participants