bincrafters / community Goto Github PK

It seems that currently our Appveyor template goes ahead and builds all configurations for a given compiler in a single build-process, i.e. debug/release/x86/x86_64/static/shared, etc.

According to Appveyor's Time limitations: All plans have 60 minutes quota per build job.

I propose that we modify the template to split the build processes by default. Either by build_type:

configuration:
  - Debug
  - Release

or by arch:

platform:
  - x86
  - x64

I also propose that builds on our CI should be marked failed immediately on error of just one build, using:

matrix:
    fast_finish: true

This way build threads are not occupied. Our CI is there to ensure that in the end all builds are correct and green, so it makes no sense to let appveyor keep building configurations even if one fails.

I prefer the arch approach of splitting builds. We also shouldn't over-partition the builds as that will be a waste probably (so no need to split by arch and build type at the same time).

The disadvantage is that each build process needs to initialize the image environment, fetch sources etc.
The advantages however as far as I can tell are (a) reduce the chance of a timeout due to a long build process, (b) easier to debug when things fail.

I am not sure if there are issues with this, otherwise I can submit a PR to the templates, so we can adopt on the recipe upgrade sprint across packages.

Model after msys_installer.

At least one customization for this template will be in .travis.yml as shown below, no need to download a docker image upon build:

matrix:
   include:
      - <<: *linux
      - <<: *osx

It looks like conan-parson has been failing since some refactoring a few weeks ago. If anybody can take and troubleshoot the current build on appveyor, it would be appreciated:

https://ci.appveyor.com/project/BinCrafters/conan-parson/build/1.0.34

MSYS, Cygwin, and Windows Subsystem for Linux (WSL) are three options for compiling Makefiles on Windows. Each of these has bash.exe, but unfortunately each seems to operate slightly differently.

For example, when using Cygwin, a command might look like this:
self.run("bash -c ^'configure^'")

While on MSYS, the same command must be run like this:
self.run("bash -c '{config_cmd}'")

I do not know what the equivalent is for WSL.

Currently, there are several tools for working with Cygwin and MSYS.
http://conanio.readthedocs.io/en/latest/reference/tools.html#tools-run-in-windows-bash

The goal is for someone who has time and experience with all three tools to determine and summarize any known challenges with writing a recipe in such a way that any of the three environments would suffice (so long as bash.exe is on the path).

Description

ICU lists "shared", "static", "files", "archive" as the possible values

shared is incorrect, the correct value is library

package

icu/59.1@bincrafters/stable

Extra information

From the configure script:

  --with-data-packaging     specify how to package ICU data. Possible values:
        files    raw files (.res, etc)
        archive  build a single icudtXX.dat file
        library  shared library (.dll/.so/etc.)
        static   static library (.a/.lib/etc.)
        auto     build shared if possible (default)
           See http://userguide.icu-project.org/icudata for more info.

• Conan version: v0.30.3
• Operating System: Linux
• Compiler+version: gcc-7.2
• Docker image: debian:latest

When switching our strategy to aggregate all github issues to this repository, I scripted the jfrog cli to update the metadata on Bintray. An example command is given below.

Currently, each time we publish a new package, we have to update the metadata manually. Using the jfrog cli a script could parse out all the information it needs from conanfile.py and/or README.md, and this step could be made much easier. We could also add a final step to our Travis or Appveyor CI process, to run the script when the branch is stable, however it's unclear if we actually want that or not.

Note: This scripting I used to create the command below was tailored to a mass one-time update, so not really useful as a starting point.

jfrog bt pu --licenses BSL-1.0 --pub-dn true --vcs-url https://github.com/bincrafters/conan-boost-accumulators --desc "Framework for incremental calculation, and collection of statistical accumulators, from Eric Niebler" --website-url https://github.com/boostorg/accumulators --github-repo bincrafters/conan-boost-accumulators --issuetracker-url https://github.com/bincrafters/conan-boost-accumulators/issues bincrafters/public-conan/Boost.Accumulators:bincraftersjfrog bt pu --licenses BSL-1.0 --pub-dn true --vcs-url https://github.com/bincrafters/conan-boost- --desc "Framework for incremental calculation, and collection of statistical accumulators, from Eric Niebler" --website-url https://github.com/boostorg/ --github-repo bincrafters/conan-boost- --issuetracker-url https://github.com/bincrafters/conan-boost-/issues bincrafters/public-conan/Boost.accumulators:bincrafters

Description

When OpenSSL is installed by conan as a shared library, libcurl fails to ./configure when being built as a shared library if there is no system openssl installed (of the same version).

This is because the ./configure script will create a conftest program, and link it against openssl. The link succeds, because conan correctly configures the relevant environment variables to find libssl.so and libcrypto.so

However, when ./configure tries to execute conftest, it does have any knowledge of where the conan libraries are (-rpath is not set at link time, LD_LIBRARY_PATH is not defined at run time)

This causes conftest to fail, and subsequently ./configure to fail as well.

package

libcurl/7.52.1@bincrafters/stable
OpenSSL/1.0.2m@conan/stable

Expected result

./configure succeeds without requiring (the correct version of) OpenSSL to be installed system-wide

Actual result

./configure fails if (the correct version of) OpenSSL is not installed system wide.

Steps to reproduce

Docker is incredibly helpful for quickly reproducing this:

FROM debian:latest

RUN apt update -y
RUN apt install -y apt-utils gcc libtool-bin automake autoconf binutils xutils-dev python-pip
RUN pip install conan
RUN conan remote add bincrafters 'https://api.bintray.com/conan/bincrafters/public-conan'
RUN conan install -o "OpenSSL:shared=True" --build="missing" libcurl/7.52.1@bincrafters/stable

Extra information

• Happens with newer libcurl versions as well

Output:

OpenSSL/1.0.2m@conan/stable: Package installed eee73bb49a625bcbca3b9b107fdfe004f9a776ab
libcurl/7.52.1@bincrafters/stable: Building your package in /root/.conan/data/libcurl/7.52.1/bincrafters/stable/build/e882cc6df8240276d23efa26b4a720522f20f662
libcurl/7.52.1@bincrafters/stable: Configuring sources in /root/.conan/data/libcurl/7.52.1/bincrafters/stable/source


libcurl/7.52.1@bincrafters/stable: Copying sources to build folder
libcurl/7.52.1@bincrafters/stable: Generator cmake created conanbuildinfo.cmake
libcurl/7.52.1@bincrafters/stable: Generator txt created conanbuildinfo.txt
libcurl/7.52.1@bincrafters/stable: Calling build()
WARN: replace_in_file didn't find pattern '  DEBUG_POSTFIX "-d"' in 'libcurl/lib/CMakeLists.txt' file.
libcurl/7.52.1@bincrafters/stable: WARN: cd libcurl &&  ./configure  --without-libidn  --without-librtmp  --without-libmetalink  --without-libpsl  --without-nghttp2 --with-ssl  --without-libssh2 --with-zlib=/root/.conan/data/zlib/1.2.11/conan/stable/package/351053dac39760023a2758a781ec2b142ea75835/lib  --disable-shared --disable-ldap
libcurl/7.52.1@bincrafters/stable: WARN: cd libcurl &&  ./configure  --without-libidn  --without-librtmp  --without-libmetalink  --without-libpsl  --without-nghttp2 --with-ssl  --without-libssh2 --with-zlib=/root/.conan/data/zlib/1.2.11/conan/stable/package/351053dac39760023a2758a781ec2b142ea75835/lib  --disable-shared --disable-ldap
checking whether to enable maintainer-specific portions of Makefiles... no
checking whether make supports nested variables... yes
checking whether to enable debug build options... no
checking whether to enable compiler optimizer... (assumed) yes
checking whether to enable strict compiler warnings... no
checking whether to enable compiler warnings as errors... no
checking whether to enable curl debug memory tracking... no
checking whether to enable hiding of library internal symbols... yes
checking whether to enable c-ares for DNS lookups... no
checking whether to disable dependency on -lrt... (assumed no)
checking for path separator... :
checking for sed... /bin/sed
checking for grep... /bin/grep
checking for egrep... /bin/grep -E
checking for ar... /usr/bin/ar
checking for a BSD-compatible install... /usr/bin/install -c
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... configure: error: in `/root/.conan/data/libcurl/7.52.1/bincrafters/stable/build/e882cc6df8240276d23efa26b4a720522f20f662/libcurl':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details
libcurl/7.52.1@bincrafters/stable: 
libcurl/7.52.1@bincrafters/stable: ERROR: Package 'e882cc6df8240276d23efa26b4a720522f20f662' build failed
libcurl/7.52.1@bincrafters/stable: WARN: Build folder /root/.conan/data/libcurl/7.52.1/bincrafters/stable/build/e882cc6df8240276d23efa26b4a720522f20f662
ERROR: libcurl/7.52.1@bincrafters/stable: Error in build() method, line 139
	self.run(configure)
	ConanException: Error 256 while executing cd libcurl &&  ./configure  --without-libidn  --without-librtmp  --without-libmetalink  --without-libpsl  --without-nghttp2 --with-ssl  --without-libssh2 --with-zlib=/root/.conan/data/zlib/1.2.11/conan/stable/package/351053dac39760023a2758a781ec2b142ea75835/lib  --disable-shared --disable-ldap
The command '/bin/sh -c conan install -o "OpenSSL:shared=True" --build="missing" libcurl/7.52.1@bincrafters/stable' returned a non-zero code: 1

config.log

configure:4477: gcc -o conftest -m64 -s -I/root/.conan/data/OpenSSL/1.0.2m/conan/stable/package/eee73bb49a625bcbca3b9b107fdfe004f9a776ab/include -I/root/.conan/data/zlib/1.2.11/conan/stable/package/351053dac39760023a2758a781ec2b142ea75835/include -DNDEBUG -m64 -L/root/.conan/data/OpenSSL/1.0.2m/conan/stable/package/eee73bb49a625bcbca3b9b107fdfe004f9a776ab/lib -L/root/.conan/data/zlib/1.2.11/conan/stable/package/351053dac39760023a2758a781ec2b142ea75835/lib conftest.c -lssl -lcrypto -ldl -lz >&5
configure:4481: $? = 0
configure:4488: ./conftest
./conftest: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory
configure:4492: $? = 127
configure:4499: error: in `/root/.conan/data/libcurl/7.52.1/bincrafters/stable/build/e882cc6df8240276d23efa26b4a720522f20f662/libcurl':
configure:4501: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details

• Conan version: v0.30.3
• Operating System: Linux
• Compiler+version: gcc-6.3
• Docker image: debian:latest

It would be great to connect to a real postgres database when building in travis/appveyor.

To take into account:

• conan_package_tools uses @lasote docker images, so we have to either install postgres inside the container or serve the database in the host and call it using TCP/IP.
  • but as far as I have tried, I cannot modify configuration of postgres in travis host to allow connections from other IPs
  • binding a port (from the host) to unix domain socket (the one used by postgres) does not work, it seems it can make the request by no response is received :/

The following exists in the build.py file for CI. It seems it would be safer overall to explicitly disallow such configuration in the configure() method of conanfile.py. However, interested in discussing further if there are other reasons/factors for doing it this way.

https://github.com/bincrafters/conan-Botan/blob/stable/2.1.0/build.py#L54

def _fix_clang_abi(build):
    compiler = build.settings['compiler']
    libcxx = build.settings['compiler.libcxx']
    if compiler == 'clang' and libcxx == 'libstdc++':
        build.settings['compiler.libcxx'] = 'libstdc++11'
    return build

Description

Shall we agree on a package naming convention? I would prefer that all package names are always lowercased. This makes it easier to remember and conforms to the way most package managers work. It is also a bit of a surprise factor for case-sensitive platforms.

UPDATE: Please express your preference at this poll @solvingj has setup: https://strawpoll.com/f8p2we5w

Whereas READMEs help people use the project, contributing docs help people contribute to the project.

It explains what types of contributions are needed and how the process works. While not every project has a CONTRIBUTING file, its presence signals that this is a welcoming project to contribute to.

libogg

WIP here: https://github.com/sztomi/conan-libogg

Status:

• macOS (local)
• Linux (local)
• Travis CI
• Windows (local)
• AppVeyor
• Move to bincrafters

I've added the opus library, from xiph, as a conan package:

https://github.com/bincrafters/conan-opus

Proof of successful builds from my fork:

https://travis-ci.org/dimi309/conan-opus/builds/312258190
https://ci.appveyor.com/project/coding3d/conan-opus/build/1.0.3

(some are still building at the time of writing but they should be fine)

I had to skip VS builds < v2015 because the library only provides a VS 2015 solution (can upgrade but can't downgrade)

Works on Linux, MacOS / OSX and Windows VS, but not MinGW because... autotools (see here: #13 (comment))

cc @SSE4 (as discussed)

When I open the address https://bincrafters.github.io I see the hydejack's favicon on my tab.

Just added log4cplus package. Apparently we had the recipe ported from memsharded but it was never set up and published. Seems to have a few build issues on windows, but I'm sure it worked at one point when memsharded finished it originally, so it should be easy to fix. Not sure if MinGW builds ever worked because it was commented out in appveyor.yml, so that may be harder to get working.

It's good to use cmake.install() when possible. However, the output Conan during package creation often looks like this as a result.

Parson/0.1.0@bincrafters/testing: Calling package()
Parson/0.1.0@bincrafters/testing package(): Copied 1 '' files: LICENSE
Parson/0.1.0@bincrafters/testing: Package '6cc50b139b9c3d27b3e9042d5f5372d327b3a9f7' created

This is less verbose than the Conan self.copy() method, making it harder to feel confident in the package contents based on the output.

Is there any universal cmake option which might help in this case?

Attention to all those who use Bincrafters Conan packages, based on the issue below, we have decided to have a vote, please let us know what you think:

https://twitter.com/bincrafters/status/938049797105299456

#8

Please don't vote or comment here.

Recipe from lasote is outdated and doesn't work with latest conans.
I have refactored it and put into https://github.com/bincrafters/conan-libxml2.

Improvements:

• uses modern conan
• uses zlib from dependencies for msvc
• example checks proper linking
• does not package junk files like testdso

libpng needs to be republished with these changes:

https://github.com/bincrafters/conan-libpng/pulls

I have online builds of other packages that are failing right now, because of missing binaries. The above mentioned pull requests will fix that.

The bulid on boost_fiber is not working after the refresh. Fortunately nothing else depends on it so I will keep moving.

Hi everyone,

I see my pull request has been accepted here:

https://github.com/bincrafters/conan-gflags/tree/testing/2.2.1

Don't forget to publish to stable if you agree with the changes 😄

We need these improvements to then proceed to publish glog too.

Initial attempt at adding MinGW to conan-lzma failed:

https://ci.appveyor.com/project/BinCrafters/conan-lzma/build/1.0.4/job/wfckab1smt798qlq

lzma/5.2.3@bincrafters/testing: Copying sources to build folder
lzma/5.2.3@bincrafters/testing: Generator txt created conanbuildinfo.txt
lzma/5.2.3@bincrafters/testing: Calling build()
'.' is not recognized as an internal or external command,
operable program or batch file.
lzma/5.2.3@bincrafters/testing: 
lzma/5.2.3@bincrafters/testing: 

Just need someone to try to fix at next opportunity

Now that we've worked with build.py for a while, it's a lot of redundant code we have to copy into all recipes. It's not great. Several people have suggested looking at different approach, making it a pip package, or perhaps submitting to conan package tools as special helper methods. Should figure this out before we go through and apply updates to all recipes.

Need volunteer to test the recipe with the latest version of FMT.

https://github.com/fmtlib/fmt/releases/tag/4.1.0

Hi!

My idea is create a simple page listing all conan packages provided by us.

The link may point to github address. e.g:
libpng
zstd

I'm not a ruby guy, but I think that should be easy to execute this issue.

This ticket is for me or @grafikrobot .

After the refresh, the iostreams test_package is failing on Appveyor. It seems very likely to the addition of lzma, which is new in our packages.

I disabled the test_package folder for now so i could get through the refresh.

Currently we're using a Non-Bincrafters (and non-working) fork of GYP for the source method. We should seek some alternative as soon as possible.

As part of the refresh, I've added mingw to libqrencode. it's currently failing on Appveyor, it would be good for someone to try to troubleshoot this. If it's not feasible or not worth the effort, then please comment it out in appveyor.yml , put a comment in this ticket, and close it.

We've identified that many libraries we package are using various means of defining -pthread in cpp_info. We'd like to see if it's possible to define some generic mechanism (perhaps contributing back to conan) for choosing a threading library for cpp_info. Perhaps Boost does this today, and if so, perhaps we can learn from it's detection strategy.

WIP here: https://github.com/sztomi/conan-openal

• macOS (local)
• Linux (local)
• Travis CI
• Windows (local)
• AppVeyor
• README
• Move to bincrafters

It's not feasible or practical for anyone to "watch" or "star" all our repositories. As people create github issues to report problems, there's a concern that nobody will get the notification. We've created a unique situation with this many repositories. We can either create a "meta" repository called "bincrafters/package-issues". Or create a trello board for the same purpose, or look at other options. Once decided, solvingj has a script that can update the "issues URL" for all packages on Bintray. But, we still need to figure out how to disable github issues on all github repositories at the same time, and potentially update all readme's with a link to whatever issues page we decide to use.

Description

Feature Request:

I have made my first steps on using conan and took glfw examples to consume your glfw package.
I took apart the examples of the glfw library as well as the deps folder and then tuned the CMakeLists.txt to include the conan specifics (https://github.com/danimtb/glfw_examples)

I have only tested the examples in Windows, Visual Studio 15. However, I think it could be a good starting point to include the examples inside test_package of the glfw conan package. I would like to ask about the community opinion about this and what would be the best approach to do so.

BTW, thank you for creating the glfw package!

package

glfw/3.2.1@bincrafters/stable (https://github.com/bincrafters/conan-glfw)

Extra information

• Conan version: v0.29.1
• Operating System: Windows
• Compiler+version: Visual Studio 15

https://github.com/bincrafters/conan-spdlog/blob/4f62824f5294da64d0013dfec9e9950ae54d3a35/conanfile.py#L18

I'm pretty sure that this should be fmt instead of fmtlib.

These adaptations are now needed for freetype to work correctly:

bincrafters/conan-freetype#4

(The build fails right now, because the changes to libpng need to be published first: #31 )

I've put it here:

https://github.com/bincrafters/conan-glog

I don't have proof of a successful build online because, for the build to work, the gflags improvements have to be published firtst: #29

But I've tested it locally and it's ok as far as I have seen.

This is for myself or @grafikrobot

So far, we're getting the following error on windows (local and appveyor):

Error seems to be:

build\feature.jam:326: in validate-feature from module feature
error: unknown feature "<segmented-stacks>"

followed by

boost_coroutine/1.66.0@bincrafters/testing:
boost_coroutine/1.66.0@bincrafters/testing: ERROR: Package '88e888e37368af209fed243261ffaf751055712f' build failed
boost_coroutine/1.66.0@bincrafters/testing: WARN: Build folder C:/.conan\tv2fxc\1
ERROR: boost_coroutine/1.66.0@bincrafters/testing: Error in build() method, line 54
        boost_package_tools.build(self)
        ConanException: Error 1 while executing b2 -j8 -a --hash=yes --debug-configuration --layout=system  coroutine-build

There is workflow problem with the conan-template and specifically the build.py.
If you look at: https://github.com/bincrafters/conan-templates/blob/master/build.py#L67

62    builder = ConanMultiPackager(
63        username=username,
64        channel=channel,
65        reference=reference,
66        upload=upload,
67         remotes=upload,  # while redundant, this moves bincrafters remote to position 0
68        upload_only_when_stable=True,
69        stable_branch_pattern="stable/*")

this assumes that:

upload = "https://api.bintray.com/conan/{0}/public-conan".format(username)

exists and contains the repo where dependencies can be found.

So, if one forks from bincrafters and tries to build a package the bincrafters' remote is not found, and in turn that prevents from using bincrafter's as a tree to lookup dependencies.

To solve this, one would have to ensure after forking that the bincrafters' remote repo is supplied, e.g. via CONAN_REMOTES.

I am not sure if this is an intended approach, but maybe we can do better? It is also a detail that people forking may not realize and thus have a hard time finding out why it is happening (took me a while to track down!)

As a very simple, yet probably also very effective way, I propose that we add to the remotes= used for CI the bincrafters' repository by default, if a CONAN_REMOTES is not provided, in the build.py.

After all this is intended to be used by us mainly, right?

I've added CI to this header-only library and the test_package is failing:

https://travis-ci.org/bincrafters/conan-spdlog/jobs/323713351#L939

undefined reference to pthread_create'`

Description

I am trying to build a small test program using some of the Boost libraries. And I'm having problems getting it to work. I call "conan install .. --build missing"

package

Boost.System/1.65.1@bincrafters/stable

Expected result

I expected that I get the missing libraries built or a message telling me what is wrong.

Actual result

It ends up with this message:
PROJECT: Installed build requirements of: Boost.System/1.65.1@bincrafters/stable
Boost.System/1.65.1@bincrafters/stable: Building your package in C:/.conan\j6ee3uqs\1
Boost.System/1.65.1@bincrafters/stable: Configuring sources in C:/.conan\cxr35fgu\1
[==================================================] 38.5KB/38.5KB
Boost.System/1.65.1@bincrafters/stable: Copying sources to build folder
Boost.System/1.65.1@bincrafters/stable: ERROR: Generator boost(file:None) failed
invalid literal for int() with base 10: '4.9'
ERROR: invalid literal for int() with base 10: '4.9'

Steps to reproduce

conanfile.txt:
[requires]
Boost.Coroutine2/1.65.1@bincrafters/stable
Boost.Fiber/1.65.1@bincrafters/stable

[generators]
cmake

~/.conan/profiles/default
[build_requires]
[settings]
os=Windows
arch=x86_64
compiler=gcc
compiler.version=4.9
compiler.libcxx=libstdc++11
build_type=Debug
[options]
[scopes]
[env]

Extra information

• Conan version: v0.29.1
• Operating System: Windows 7
• Compiler+version: gcc.exe (x86_64-posix-seh-rev3, Built by MinGW-W64 project) 4.9.2
• Docker image: ? I don't use docker

Hi!

When a new one creates an issue, would be nice to get some information to guide what it needs.

I'm thinking some like Catch: https://github.com/catchorg/Catch2/issues/new
Also, we can include the package name as required

Github supports templates for issue and PR:
https://github.com/blog/2111-issue-and-pull-request-templates

We have agreed to add a page with information, tips and tricks about consuming and using conan packages. Matters covered could be typical usage scenarios, common pitfalls across different packages, how to properly use a package when your project only contains a conanfile.txt and you then need to execute "naked" cmake or other build commands, etc.
The idea is not to get into too advanced details about conan or specific packages, but to provide an overall guide of how to use conan effectively in practice, based on our experience of doing so ourselves and the insights we have developed while packaging and testing various libraries.

      if self.settings.os == "Linux":
           # if shared:
           # self.copy(pattern="*.so*", dst="lib", src=os.path.join(self.FOLDER_NAME, "lib", ".libs"))
           self.copy("*.a", dst="lib", src=os.path.join(self.pq_source_dir, "src", ".libs"))
       elif self.settings.os == "Windows":
           self.copy("*.lib", dst="lib", src=os.path.join(self.pq_source_dir, "lib"))
           self.copy("*.bin", dst="bin", src=os.path.join(self.pq_source_dir, "lib"))

Should be changed to

        if self.settings.os == "Windows":
            self.copy("*.lib", dst="lib", src=os.path.join(self.pq_source_dir, "lib"))
            self.copy("*.bin", dst="bin", src=os.path.join(self.pq_source_dir, "lib"))
        else:
            # if shared:
            # self.copy(pattern="*.so*", dst="lib", src=os.path.join(self.FOLDER_NAME, "lib", ".libs"))
            self.copy("*.a", dst="lib", src=os.path.join(self.pq_source_dir, "src", ".libs"))

Also, it'd sure be nice if that if shred were re-enabled in general. Although currently only needing static.

Microsoft has released new minor version. Need to publish an update after the refresh.

I've added Google's double conversion library, as a conan package:

https://github.com/bincrafters/conan-double-conversion

Proof of successful builds from my fork:

https://ci.appveyor.com/project/coding3d/conan-double-conversion/build/1.0.4
https://travis-ci.org/dimi309/conan-double-conversion/builds/314002170

(some are still building at the time of writing but they should be fine)

Works on Linux/MacOS/Windows, most likely also on MinGW even though I haven't tried it there yet.

Currently CMake's find_package() does not work with the boost packages. I just created an experimental custom FindBoost.cmake:

function(add_cloned_imported_target dst src)
    add_library(${dst} INTERFACE IMPORTED)
    foreach(name INTERFACE_LINK_LIBRARIES INTERFACE_INCLUDE_DIRECTORIES INTERFACE_COMPILE_DEFINITIONS INTERFACE_COMPILE_OPTIONS)
        get_property(value TARGET ${src} PROPERTY ${name} )
        set_property(TARGET ${dst} PROPERTY ${name} ${value})
    endforeach()
endfunction()

function(first_character_to_upper dst src)
    string(SUBSTRING ${src} 0 1 first)
    string(SUBSTRING ${src} 1 -1 remaining)
    string(TOUPPER ${first} FIRST)
    set(${dst} ${FIRST}${remaining} PARENT_SCOPE)
endfunction()

foreach(component ${Boost_FIND_COMPONENTS})    
    if(NOT TARGET Boost::${component})
        first_character_to_upper(Compontent ${component})
        add_cloned_imported_target(Boost::${component} CONAN_PKG::Boost.${Compontent})
    endif()
endforeach()
set(Boost_FOUND TRUE)

I also created a conan package for my FindBoost file:

from conans import ConanFile, CMake, tools

class FindConanBoost(ConanFile):
    name = "FindConanBoost"
    version = "0.1"
    license = "<Put the package license here>"
    url = "<Package recipe repository url here, for issues about the package>"
    description = "<Description here>"
    generators = "cmake"
    exports_sources = "FindBoost.cmake"

    def package(self):
        self.copy("FindBoost.cmake", dst=".", keep_path=False)

Now I can just add the FindConanBoost package to my requirements together with the bincraft boost packages and find_package works now, even with transitive dependencies:

find_package(Boost COMPONENTS test)
target_link_libraries(MyApp Boost::test)

TODO: version check, optional components

See also my issue here: conan-io/conan#2125

This has come up before, but I don't recall the solution. There are quite a few google results about it, but none show a clear and acceptable solution.

Posting issue here so it can be searched later.

It's worth noting that I'm using lasote's docker images for clang and GCC. Both produce the error:

fatal: unable to access 'https://github.com/Microsoft/GSL.git/': Problem with the SSL CA cert (path? access rights?)

https://travis-ci.org/bincrafters/conan-gsl_microsoft/builds/324239834#L871

Description

I was attempting to install my project's sole requirement cpprestsdk which, among other libraries, relies on websocketpp.
The installation process fails when it reaches the point to install websocketpp with an ImportError.

package

List of relevant packages involved:

• cpprestsdk/2.9.1@bincrafters/stable, requires
  • websocketpp/0.7.0@bincrafters/stable

Expected result

Installation of websocketpp to be successful.

Actual result

The installation process is blocked with the following error message:

ERROR: Unable to load conanfile in ****/.conan/data/websocketpp/0.7.0/bincrafters/stable   /export/conanfile.py
  File "****/.conan/data/websocketpp/0.7.0/bincrafters/stable/export/conanfile.py", line 1, in <module>
    from conans import ConanFile, tools, os
ImportError: cannot import name os

Steps to reproduce

• Create conanfile.txt in the root of a CMake based project like follows:

  [requires]
  cpprestsdk/2.9.1@bincrafters/stable
  
  [generators]
  cmake
  

• Configure CMakeLists.txt as follows:

  cmake_minimum_required(VERSION 3.9)
  project(test_cpp)
  
  set(CMAKE_CXX_STANDARD 11)
  
  include(build/conanbuildinfo.cmake)
  conan_basic_setup()
  
  add_executable(test_cpp test.cpp)
  
  target_link_libraries(test_cpp ${CONAN_LIBS})
  

• mkdir build && cd build && conan install ..
• Observe the console until it reaches the point to process websocketpp and fail.

Extra information

I found this conan-gsl_microsoft PR addressing a similar issue. I was able to successfully install websocketpp by manually editing my local ****/.conan/data/websocketpp/0.7.0/bincrafters/stable/export/conanfile.py like in the mentioned PR, changing from:

from conans import ConanFile, tools, os

to:

from conans import ConanFile, tools
import os

• Conan version: v0.29.2
• Operating System: macOS 10.13.1
• Compiler+version: gcc-4.2.1

Description

When gtest 1.8.0 was pushed a month ago, it was simply done on the stable branch, and no testing/1.8.0 branch got created. I just created this branch off the stable one and for some reason it's failing on MSVC15.

Of note, the Travis build failed immediately due to the Conan/Travis changes, so i've fixed that on the testing branch. Travis is now passing. When this MSVC issue is resolved, we need to merge changes into stable/1.8.0 and let it rebuild.

Here's the git repo:
https://github.com/bincrafters/conan-gtest

Here's the failing Appveyor build:
https://ci.appveyor.com/project/BinCrafters/conan-gtest/build/1.0.3

package

gtest/1.8.0@bincrafters/testing

Extra information

• Conan version: v0.30.3
• Operating System: Windows
• Compiler+version: MSVC15

https://xiph.org/downloads/

WIP here: https://github.com/sztomi/conan-flac

• macOS (local)
• Linux (local)
• Travis CI
• Windows (local)
• AppVeyor
• README
• Move to bincrafters

Generic issue title since more might come up, once the former issue(s) is solved.

To beginn with: Clang fails for Boost.Container because of an invalid argument option

https://travis-ci.org/inexorgame/inexor-core/jobs/319883640#L3279

which seems to come from

https://github.com/bincrafters/conan-Boost-Generator/blob/5d6e53320cda093c42b1316745689fd773ff2ca2/conanfile.py#L277