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

Conan package #304

Open
helmesjo opened this Issue Jan 5, 2019 · 67 comments

Comments

4 participants
@helmesjo
Copy link

helmesjo commented Jan 5, 2019

I'm writing a conan recipe for Magnum (already got one for Corrade successfully building). I've wrestled a few days now with these issues (each try takes a lot of time) so I'd thought I'd look for some help/ideas here!

Issue

I'm building conan packages for GCC, Clang (etc.) inside docker containers.
In the conan recipe, prior to building magnum, it installs libgl1-mesa-dev (or libgl1-mesa-dev:i386 respectively) on the host. But when later building, it either:

  1. Fails to find OpenGL libs when targeting x86 (for all builds on Ubuntu) if only installing libgl1-mesa-dev:i386:
    CMake Error at /usr/share/cmake-3.12/Modules/FindPackageHandleStandardArgs.cmake:137 
    (message):
        Could NOT find OpenGL (missing: OPENGL_opengl_LIBRARY OPENGL_glx_LIBRARY)
    
    Above can be fixed* (for all but Ubuntu Trusty) by installing both libgl1-mesa-dev & libgl1-mesa-dev:i386 (in that order, else 1. happens again), but then it:
  2. fails to link OpenGL (error adding symbols: File in wrong format) on Ubuntu Bionic & Cosmic when targeting x86 (it appears link the 64bit lib).

*There are a lot of issues with multiple mesa-dev packages on the same host.

Details:

  • CMake 3.12
  • Ubuntu x64: Trusty (GCC 4.9), Xenial (GCC 5), Artful (GCC 6 & 7, Clang 3.9. 4, 5), Bionic (GCC 8, Clang 6), Cosmic (Clang 7) (using the conan docker images)

So, any ideas? Anyone seen similar issues? Am I missing something obvious?

@helmesjo helmesjo changed the title [Help Needed]: Issues cross building to x86 on x86_64 Ubuntu host [Help Needed]: OpenGL issues when cross building to x86 on x86_64 Ubuntu host Jan 5, 2019

@helmesjo helmesjo changed the title [Help Needed]: OpenGL issues when cross building to x86 on x86_64 Ubuntu host OpenGL issues when cross building to x86 on x86_64 Ubuntu host Jan 5, 2019

@mosra mosra added this to TODO in Platforms via automation Jan 5, 2019

@mosra

This comment has been minimized.

Copy link
Owner

mosra commented Jan 5, 2019

Yay, Conan! 😍 There's an in-progress Hunter package as well (#298), so with this it's complete :)

If I see correctly, this happens only when cross-compiling from 64b to 32b, right? In my experience, building natively on either 32b or 64b never had any issues (in particular, I have a Travis CI build and it also needed just libgl1-mesa-dev).

I wanted to suggest looking at how other CMake-based packages handle this, but seeing your other open issues (bincrafters/community#602 / bincrafters/community#603), it seems you already tried that. Other ideas:

  • (I have no idea how Conan works, but) is it possible to supply location of these libraries explicitly? That's the final solution when everything else fails and always did the job for me. Magnum doesn't need the headers, just the libs.
  • FindOpenGL in CMake 3.10 switched to preferring GLVND, if found, and I'm opting-in for that. The error message looks like it tried to find GLVND (so libOpenGL.so + libGLX.so instead of libGL.so) and failed. I have no idea what Ubuntu ships, it's possible that the older versions don't supply these libraries at all. However, in that case FindOpenGL should fall back to the old thing if I understood correctly. Maybe something related to the cross-compilation where FindOpenGL assumes something it shouldn't? Maybe the compat 32b libraries don't ship the GLVND things?
@helmesjo

This comment has been minimized.

Copy link
Author

helmesjo commented Jan 5, 2019

Yeah, conan is a dream come true (once the packages are in place)! 😇

From what I can tell (I've been staring at this too hard recently, so my brain is pretty cooked), yes the issue is only related to cross building from a x64 host to x86. Building natively is probably a sane path to go considering all issues around OpenGL libs in general (been seeing a lot in my google quest). I'll probably try this first.

  1. Yes, conan recipes are just the glue for downloading, building & packaging software, and written in python so patching/fixing up of any sort is rather "trivial". For example, find_package allows "hints" of where it should look first. I could replace all find_package related to OpenGL with an equivalent that also specifies the path. Then it's just a matter of reliably obtaining the correct path (shouldn't be too hard in linux I assume).

  2. Yeah, something is probably off with the FindOpenGL-script regardless. It should be "target arch"-aware and select the correct one... But those scripts are all just "naive brute force locators", so I guess one can't expect too much magic... 🎆

Thanks for the feedback! I'll keep digging!

@mosra

This comment has been minimized.

Copy link
Owner

mosra commented Jan 5, 2019

I think it should be possible to dig the problem out of the FindOpenGL script and fix it (after all, the core of the problem is just a file not being found in this particular crosscompilation setup), but then:

  • if I submit a PR to CMake, it'll be a year or so until it gets integrated & released, not to mention conan will probably not jump to latest and greatest CMake right away
  • I could maintain the forked/fixed version inside magnum, but this stuff is so complex right now given GLVND and all that stuff that I'd rather rely on CMake devs having the responsibility

I think the more straightforward way would be to just build natively on 32bit. Besides that, didn't Ubuntu ditch 32bit support for the latest release already (19.04)? I heard something related to that.

@helmesjo

This comment has been minimized.

Copy link
Author

helmesjo commented Jan 5, 2019

I agree, and did just that! Now we'll just have to wait and see if this goes from red to green! 😊
Build Status Build Status AppVeyor

@Croydon

This comment has been minimized.

Copy link

Croydon commented Jan 5, 2019

Hi @mosra!
Nice to see that you are interested in Conan as well!
Would you be interested in providing official support for Conan once the recipe is stable?
We can help you to setup everything which is required if you want 😄

Otherwise, I believe @helmesjo is going to include the recipes in @bincrafters and we are maintaining it there, but obviously official support is always nicer 😄

@helmesjo

This comment has been minimized.

Copy link
Author

helmesjo commented Jan 5, 2019

Alright, so native builds did the trick. Closing this for now!

@helmesjo helmesjo closed this Jan 5, 2019

Platforms automation moved this from TODO to Done Jan 5, 2019

@mosra

This comment has been minimized.

Copy link
Owner

mosra commented Jan 6, 2019

@helmesjo yay!

@Croydon I'm afraid I don't have the capacity to provide official support (as in maintaining them myself), I'm already offloading Vcpkg and Debian package support to people who are using those platforms directly -- because they can spot the issues much easier. What I can do, however, (and what I'm usually doing), is reviewing them to ensure they provide all desired options and features (and also pinging you in case a new version is about to get released).

@Croydon

This comment has been minimized.

Copy link

Croydon commented Jan 6, 2019

You could still ping us at any time when either CI or users are complaining about problems, so it would be more reviewing then maintaining by yourself. We (as in Bincrafters) kinda have this relationship with the maintainer of Flatbuffers, as he doesn't know much about Conan as well: https://github.com/google/flatbuffers/commits/master/conanfile.py

But if you don't feel comfortable with this is also fine and we will go ahead at @bincrafters 😄

@mosra

This comment has been minimized.

Copy link
Owner

mosra commented Jan 6, 2019

Right, so what the stuff I need to do for this semi-official support? :) Looking at flatbuffers, I see just conanfile.py there + a large build matrix in .travis.yml, while https://github.com/helmesjo/conan-magnum has many more files. If it would be about just maintaining conanfile.py directly in this repository, I'm all for it. This also means if there's a problem, it doesn't depend just on PRs to @helmesjo's repository, but anybody can just pick it up from the main magnum repo and fix it.

But ... the problem I see here is that I already have quite a huge build matrix (see here: https://magnum.graphics/build-status/) and adding a dozen of other jobs just for Conan will make it unusable, since the builds would take forever (it's already bad enough with AppVeyor taking 2+ hours). Is there a way around that?

@Croydon

This comment has been minimized.

Copy link

Croydon commented Jan 6, 2019

The amount of files is depending on the question if we would use your CI or another one. If it is only about minimal Conan support without CI support, then this would be conanfile.py + test_package https://github.com/helmesjo/conan-magnum/tree/stable/2018.10/test_package

All of the other files are only needed to get the CI + publishing going (see https://github.com/bincrafters/conan-templates-upstream as a reference)

We could maintain conanfile.py + test_package (= 4 files in total) here and use our Bincrafters CI and repository to publish the build packages

@helmesjo

This comment has been minimized.

Copy link
Author

helmesjo commented Jan 6, 2019

Just the last piece of the puzzle... (semi-related to this issue so I hope it's ok to ask here 😇 ):

I fixed the link order, and also added OpenGL to the link list (all of this is applied to packages depending on Magnum), and in the process added a line in the test package that verifies all is linked correctly (this is like a mini-package depending on Magnum & build+run by conan after building Magnum, just for verification).
This worked dandy for all but MacOS, which just anonymously fails when executing the test package...

@mosra Do you know of anything else that is required on Mac? A package that needs to be installed? Some other framework that needs to be linked/added for Mac? Could this be a Travis+Mac thing?

@mosra mosra changed the title OpenGL issues when cross building to x86 on x86_64 Ubuntu host Conan package Jan 6, 2019

@mosra mosra reopened this Jan 6, 2019

Platforms automation moved this from Done to In progress Jan 6, 2019

@Croydon

This comment has been minimized.

Copy link

Croydon commented Jan 6, 2019

@helmesjo I quickly deleted my message(😁) as it didn't see related on a second thought, even more since this is the case on all configurations but only macOS fails.

@helmesjo

This comment has been minimized.

Copy link
Author

helmesjo commented Jan 6, 2019

Haha np. Yeah also that target is optional (unless building tests). But I changed Corrade to build with_testsuite=True nonetheless, to be consistent with the main repo.

@Croydon

This comment has been minimized.

Copy link

Croydon commented Jan 6, 2019

Is this testsuite there to test magnum/corrade itself or applications using it? In the first case it should stay disabled

@helmesjo

This comment has been minimized.

Copy link
Author

helmesjo commented Jan 6, 2019

It's for magnum & corrade from what I can tell, so yes it adds unnecessary build time for sure. You know what, I'll set it to false again! 😄

@mosra

This comment has been minimized.

Copy link
Owner

mosra commented Jan 6, 2019

uh oh, slow down, i am unable to type so fast 😅

I hope it's ok to ask here 😇

Sure, of course ;) since it's now mainly about Conan, I'm renaming and reopening.

link order

different default value

There's Using Magnum with custom buildsystems in the documentation, listing link order and all main packages of magnum and corrade. All of them should be present in the options (IIRC Trade and DebugTools were missing) and those which are deprecated (Shapes and GlutApplication) don't have to be there at all, since I will be removing them soon anyway. The default values should match the defaults from option() calls in root CMakeLists.txt, except maybe for Sdl2Application, which is good to have by default.

Not sure if there's something other from the option()s that's missing in the package options, tho.

Is this testsuite there to test magnum/corrade itself or applications using it?

It's a whole test suite framework (see the docs) and I'm encouraging the library users to use it as well, since it's well integrated with the lib and has some features others don't. But apps can be tested by anything else as well, so it's completely optional (but enabled by default, yes). Building of tests is controlled by BUILD_TESTS, BUILD_GL_TESTS and BUILD_AL_TESTS CMake options and I don't think enabling these makes any sense, nor including them in the package options.

added OpenGL to the link list

Hmm. For some reason I thought Conan is CMake-based and this all would be handled transitively by CMake. Isn't that the case?

If not, then PluginManager, Sdl2Application and GlutApplication needs to link to libdl on Linux, and then, in case you build the Audio library as well, it depends on OpenAL. This should be all I think, there are some extra deps for iOS and Android, but you don't handle those platforms yet, right?

For OpenGL there's an ability to use GLES (TARGET_GLES etc.), in which case it doesn't link to libGL on Linux but to libGLES. That's mainly for platforms like RPi. Not sure how to handle that (or if Conan supports such platforms).

The amount of file is depending on the question if we would use your CI or another one.

Since that would mean blowing up the job count, I think this would need to be on your CI, then. For all other packages I'm having stuff inside the package/ directory, so there could be package/conan/ containing the conanfile.py and the test cmake + cpp file. Would that help with anything?

@helmesjo

This comment has been minimized.

Copy link
Author

helmesjo commented Jan 6, 2019

Ah sweet, that was the documentation I was thinking about but never actually searched for... 😊
I'll look into this!

@Croydon

This comment has been minimized.

Copy link

Croydon commented Jan 6, 2019

It's a whole test suite framework (see the docs) and I'm encouraging the library users to use it as well, since it's well integrated with the lib and has some features others don't. But apps can be tested by anything else as well, so it's completely optional (but enabled by default, yes).

Alright then, sorry @helmesjo, maybe your first instinct was right and True should be the default value. Maybe we need to slow down a bit :)

Hmm. For some reason I thought Conan is CMake-based and this all would be handled transitively by CMake. Isn't that the case?

Conan can work together with absolutely all build systems. However, for the common ones it ships a lot of helper tools to deal with common scenarios and glue together the Conan world with the build system's one. For CMake Conan can in theory detect the libraries automatically, however, only with some limitations. For example, it can't detect the right order to link stuff and sometimes the order is important. Also it might not be perfect and misses libraries out. For these reasons recipes who want to be included in the official conan-center should list the libraries manually.

To understand this a little bit better: Even Magnum is using CMake, consumers of Magnum might not, so Conan needs to translate all of these information between different building systems. So even consumers might use Meson it still links all libraries in the correct order.

This should be all I think, there are some extra deps for iOS and Android, but you don't handle those platforms yet, right?

Conan can handle those platforms, but typically we don't deliver for this platforms. At least not right now, who knows what the future brings :)

@mosra

This comment has been minimized.

Copy link
Owner

mosra commented Jan 6, 2019

For these reasons recipes who want to be included in the official conan-center should list the libraries manually.

Yeah, now I get you completely, thanks.

So, looking in FindMagnum.cmake and FindCorrade.cmake should help you getting the various dependencies. Just the highlighted portion and the various if(_component STREQUAL something) inside are important. As a rule the project itself has no external dependencies but the components (might) have. I don't remember the particulars from the top of my head (especially related to X11-related things, GL and Vulkan), so that's why I'm delegating you there. Sorry about this not being clearly documented yet, it's on my TODO list, but the TODO list has also hundreds of other items 😉

but typically we don't deliver for this platforms

Sure, it's easy to enable these platforms later, if someone would need them.

@mosra mosra added this to the 2019.01 milestone Jan 6, 2019

@Croydon

This comment has been minimized.

Copy link

Croydon commented Jan 6, 2019

Since that would mean blowing up the job count, I think this would need to be on your CI, then.

This is fine, we can use Bincrafters' CI 👍

For all other packages I'm having stuff inside the package/ directory, so there could be package/conan/ containing the conanfile.py and the test cmake + cpp file. Would that help with anything?

The test_package directory can be anywhere you want. I'm not 100% sure about the conanfile.py, however. It should work to have it in package/, when we are doing it like in the hunter package: The recipe itself is downloading the source again from GitHub. This is a small sidestep from our common practice to have what we call in-source recipes when we have official recipes, but it should be fine. In-source recipes are making direct use of the projects source file around the recipe file and doesn't need to download them again from somewhere. This also allows user to check out a random git commit and still being able to install it via Conan. If we write it like an out-of-source recipe it can only install the release version it has hard coded in it. Of course, this is only relevant for people directly installing it from the git repository. When installing from a Conan repository you just pick the release version anyway via the reference,
e.g. conan install corrade/2018.10@mosra/stable

@Croydon

This comment has been minimized.

Copy link

Croydon commented Jan 6, 2019

To do for Corrade (Magnum can be done afterwards much more easily)

  • Getting Corrade working at https://github.com/helmesjo/conan-corrade
    • I'm leaving it to @helmesjo to decide when this is (initially) "done"
  • Creating a Conan org + repository on Bintray for your Conan recipes, e.g. magnum/public-conan
    • In order to get the recipes eventually into conan-center, we need to upload it to a Conan repository on Bintray. In theory we could of course use our Bincrafters one but this would be rather uncommon giving the fact that you are official approving the recipes. So I would strongly advocate that you are getting a free account on Bintray, creating a Bintray organisation with a name like magnum (or any other name you are comfortable with) and are adding the bincrafters-user account which is acting as our upload bot. This would also make it look more official + we can work together seemlessly, but still keep it technically separate. If you should ever decide to use another CI system, you can do that without any interruption for users.
  • Creating pull request for Corrade which is adding the conanfily.py + CMakeLists.txt + test_package in package/conan + it should probably get a README.md to explain how to use Conan
  • @Croydon: Setting up the CI scripts in https://github.com/bincrafters/conan-corrade + adding @helmesjo & @mosra as collaborators
@helmesjo

This comment has been minimized.

Copy link
Author

helmesjo commented Jan 9, 2019

Corrade has also an WITH_UTILITY option, disabling it will result in a library that has no C++ sources, just the global Corrade.h header and various CMake utilities. Then there's WITH_RC, which enables only the corrade-rc compiler. Building with everything disabled except for WITH_RC can be useful in cross-compiling context, where you only need a native corrade-rc but everything else cross-compiled.

Oh, I missed these... (dependant options doesn't show up when running cmake .. -L (list all options). They apparently only show if the condition is met 🙃).
I'm not too high on dependant options though... What default values to we want? True for both?

cmake_dependent_option(WITH_UTILITY "Build Utility library" ON "NOT WITH_INTERCONNECT;NOT WITH_PLUGINMANAGER;NOT WITH_TESTSUITE" ON)
cmake_dependent_option(WITH_RC "Build the corrade-rc utility" ON "NOT WITH_UTILITY" ON)

And do we want similar behavior in the recipe? Something like:

if not self.options.with_interconnect and not self.options.with_pluginmanager and not self.options.with_testsuite:
    self.options.add("with_utility", True)

Or should it be declared with the rest, and just ignored if conditions not met?

if self.options.with_interconnect or self.options.with_pluginmanager or self.options.with_testsuite:
    self.options.remove("with_utility")

And the same for WITH_RC.

@mosra

This comment has been minimized.

Copy link
Owner

mosra commented Jan 9, 2019

Both UTILITY and RC are enabled by default. For the record, a set of all options and their defaults is listed here for Corrade and here for Magnum.

They apparently only show if the condition is met 🙃

Yes, that's kinda the point, so people don't configure a combination that doesn't build :)

And do we want similar behavior in the recipe?

I don't think so, no, the logic is a bit complex and having it on two places would only lead to maintenance nightmares :) Let users choose whatever they want in the Python interface and CMake will figure out what's appropriate from that. The dependencies also sometimes change between releases and it's not really something users need to be aware of, so neither the package has to be. I think.

@helmesjo

This comment has been minimized.

Copy link
Author

helmesjo commented Jan 9, 2019

I don't think so, no, the logic is a bit complex and having it on two places would only lead to maintenance nightmares :) Let users choose whatever they want in the Python interface and CMake will figure out what's appropriate from that. The dependencies also sometimes change between releases and it's not really something users need to be aware of, so neither the package has to be. I think.

I agree. See the change here.

Unless there is anything else, I'd consider conan-corrade done if the builds pass (@Croydon):
Build Status Travis
Build Status AppVeyor

@helmesjo

This comment has been minimized.

Copy link
Author

helmesjo commented Jan 9, 2019

Sorry, forgot to change the default value for build_deprecated (set to True).

@mosra

This comment has been minimized.

Copy link
Owner

mosra commented Jan 9, 2019

Just this is missing I think (from my comment above):

I'm not sure about the "build_tests" options, frankly I would just remove them, since they have use only for library developers, not users.

And I would order the options alpabetically, maybe, so it's easier to update them later. :)

Thanks for all the work so far 👍

@helmesjo

This comment has been minimized.

Copy link
Author

helmesjo commented Jan 9, 2019

Done!

@mosra

This comment has been minimized.

Copy link
Owner

mosra commented Jan 9, 2019

Wonderful! So now it's up to @Croydon to submit a PR adding these files to Corrade? :)

@helmesjo

This comment has been minimized.

Copy link
Author

helmesjo commented Jan 9, 2019

I believe so! ☺️

@helmesjo

This comment has been minimized.

Copy link
Author

helmesjo commented Jan 20, 2019

I just did a fresh build on my linux comp with GCC 8 and got a new linking error:

../libMagnumMeshTools-d.a(Compile.cpp.o): in function `Magnum::GL::Attribute<0u, Magnum::Math::Vector2<float> >::vectorSize() const':
../source_subfolder/src/Magnum/GL/Attribute.h:299: undefined reference to `Magnum::GL::Implementation::FloatAttribute::size(int, Magnum::GL::Implementation::FloatAttribute::DataType)'
/usr/bin/ld: ../lib/libMagnumMeshTools-d.a(Compile.cpp.o): in function `Magnum::GL::Attribute<1u, Magnum::Math::Vector2<float> >::vectorSize() const':
../source_subfolder/src/Magnum/GL/Attribute.h:299: undefined reference to `Magnum::GL::Implementation::FloatAttribute::size(int, Magnum::GL::Implementation::FloatAttribute::DataType)'
/usr/bin/ld: ../lib/libMagnumMeshTools-d.a(Compile.cpp.o): in function `Magnum::GL::Attribute<3u, Magnum::Math::Color4<float> >::vectorSize() const':
../source_subfolder/src/Magnum/GL/Attribute.h:299: undefined reference to `Magnum::GL::Implementation::Attribute<Magnum::Math::Vector<4ul, float> >::size(int, Magnum::GL::Implementation::Attribute<Magnum::Math::Vector<4ul, float> >::DataType)'
/usr/bin/ld: ../lib/libMagnumMeshTools-d.a(Compile.cpp.o): in function `Magnum::GL::Attribute<0u, Magnum::Math::Vector3<float> >::vectorSize() const':
../source_subfolder/src/Magnum/GL/Attribute.h:299: undefined reference to `Magnum::GL::Implementation::Attribute<Magnum::Math::Vector<3ul, float> >::size(int, Magnum::GL::Implementation::Attribute<Magnum::Math::Vector<3ul, float> >::DataType)'
/usr/bin/ld: ../lib/libMagnumMeshTools-d.a(Compile.cpp.o): in function `Magnum::GL::Attribute<2u, Magnum::Math::Vector3<float> >::vectorSize() const':
../source_subfolder/src/Magnum/GL/Attribute.h:299: undefined reference to `Magnum::GL::Implementation::Attribute<Magnum::Math::Vector<3ul, float> >::size(int, Magnum::GL::Implementation::Attribute<Magnum::Math::Vector<3ul, float> >::DataType)'
collect2: error: ld returned 1 exit status
gmake[2]: *** [src/renderer/CMakeFiles/renderer.dir/build.make:205: src/renderer/renderer-d] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:585: src/renderer/CMakeFiles/renderer.dir/all] Error 2
gmake: *** [Makefile:141: all] Error 2

The missing definition is part of the MagnumGL target.

I solved it by changing link order from:

    MagnumText
    MagnumDebugTools
    MagnumSdl2Application
    MagnumTextureTools
    MagnumShaders
    MagnumPrimitives
    MagnumGL // <----------------------
    MagnumSceneGraph
    MagnumMeshTools
    MagnumTrade
    Magnum
    GL
    MagnumText
    MagnumDebugTools
    MagnumSdl2Application
    MagnumTextureTools
    MagnumShaders
    MagnumPrimitives
    MagnumSceneGraph
    MagnumMeshTools
    MagnumTrade
    MagnumGL // <----------------------
    Magnum
    GL

Moving it to after MagnumTrade specifically

Looking at the dependency order I can't really tell why this is the case.
@mosra
Could you enlighten me? What am I missing? Besides above, are the rest looking ok? :)

helmesjo added a commit to helmesjo/conan-magnum that referenced this issue Jan 20, 2019

@mosra

This comment has been minimized.

Copy link
Owner

mosra commented Jan 20, 2019

Ha, you found a bug in the diagram :) Sorry!

MeshTools depends on GL and on Trade, will fix that in the diagram.

The rest looks okay, though I think you can drop all references to Shapes and GlutApplication, as I will be removing these soon anyway. Also, the MagnumMath and MagnumAnimation libs don't exist (are part of the core Magnum lib), so they don't need to be in the list at all.

EDIT: fixed docs uploaded

@helmesjo

This comment has been minimized.

Copy link
Author

helmesjo commented Jan 20, 2019

Ahhh, good old cache. I was confusingly staring at the previous docs for a few minutes before it correctly refreshed to the new one. 😊

Alright, I'll make those changes as well.

Thanks!

helmesjo added a commit to helmesjo/conan-magnum that referenced this issue Jan 20, 2019

@mosra

This comment has been minimized.

Copy link
Owner

mosra commented Jan 29, 2019

@helmesjo @Croydon I'll be tagging a v2019.01 later this week, is there anything important that should be done re the Conan package before the version is tagged? Since, due to how the roadmap is looking right now, the next tag probably won't be sooner than in another ~four months.

@helmesjo

This comment has been minimized.

Copy link
Author

helmesjo commented Jan 29, 2019

I'm a little bit zoned out of context right now, but no, I don't think so... :) 🤞

@mosra

This comment has been minimized.

Copy link
Owner

mosra commented Feb 4, 2019

Will be tagging v2019.01 today (it's 4 days late already), so I guess this has to wait until the next tag :)

@mosra mosra modified the milestones: 2019.01, 2019.0b Feb 4, 2019

@helmesjo

This comment has been minimized.

Copy link
Author

helmesjo commented Feb 4, 2019

Yep, guess so! What is the next step here anyways? Also, since the apple clang builds are still failing we have some more to do regardless. :)

@mosra

This comment has been minimized.

Copy link
Owner

mosra commented Feb 4, 2019

Next step is I guess something similar to what was done in mosra/corrade#57 -- adding the conanfile.py etc. directly to the Magnum repository. After that, setting up the Conan side of things (CIs, binary packages etc.).

Clang builds are failing because sdl2 was not found 🤔

@helmesjo

This comment has been minimized.

Copy link
Author

helmesjo commented Feb 5, 2019

Clang builds are failing because sdl2 was not found 🤔

Oh, you are right... I just expected the error to be the same as the first builds (test executable dying mysteriously). Must have been some cleaning of old packages happening in the Bincrafters repo.

I'll up to sdl2 2.0.9 (from 2.0.8) and hopefully it has all the packages necessary.

@helmesjo

This comment has been minimized.

Copy link
Author

helmesjo commented Feb 5, 2019

There we go. Now it's back to the old "insta death" when running the test executable.
I have an old Mac Mini at home... I'll revive it and try to debug. :)

@mosra

This comment has been minimized.

Copy link
Owner

mosra commented Feb 5, 2019

Hmm. Could it be due to this line? It requires an active GL context (which is, of course, not available, and moreover it can't ever be on Travis, as you have no GPU access there). While this might have randomly worked on Linux, I suspect that on mac this results in calling a null function pointer or something like that, causing the crash.

Can you remove the line and retry?

@helmesjo

This comment has been minimized.

Copy link
Author

helmesjo commented Feb 5, 2019

That makes sense! Just pushed the change.

@helmesjo

This comment has been minimized.

Copy link
Author

helmesjo commented Feb 5, 2019

Yep, that appears to have done the trick!

@mosra

This comment has been minimized.

Copy link
Owner

mosra commented Feb 5, 2019

Yay!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment