conan-io / conan Goto Github PK

Hi Conaneros,

More of a request for comments than anything else, really. I find I have a lot of files in the root of my project, for different CI systems, CMake files, etc. It just becomes a bit messy and I'm a bit OCD :-) Due to this I am trying to minimise at least the number of visible files. I'm wondering if you think that conan should support .conanfile.txt in addition to conanfile.txt or if this just makes it harder for users to know that a project uses conan?

Thanks for your time

Marco

I recently tried to provide a conanfile for GLFW3, but ran into quite a lot of trouble
with the package_info function, because it runs before any other function. Therefore changing the cpp_info based on the build or package output seems impossible.

GLFW3 depends on a variety of platform-specific dependencies while on Windows and OSX these usually stay the same, there can be differences between distros, so pkg-config is the common way to resolve these dependencies. So I tried running package config with a custom PKG_CONFIG_PATH to pickup the outputted glfw3.pc by the build process, but package_info is run before build.

The related file: https://gist.github.com/trevex/e34cf5dc390909488b94

Is there a way to incorporate the capability to change the cpp_info after the build and/or package pass? Also an alternative to self.run that returns the stdout and exit-code would be handy. Another issue was that the working directory of the package_info path is unclear, is it run in the package directory or source?

The support of "output"-based package-info would benefit other more complex libraries as well, e.g. GUI libraries (wxwidges et cetera).

Conan generate file with LF line ending

Hi,

Not quite sure if this is a conan issue or not, but thought I'd mention it in case it is. So I've started consuming LibXml for Linux, and the conan part of it works fine (download, install, etc) [1]. However, FindLibXml then reports this:

- Found LibXml2: /usr/lib/x86_64-linux-gnu/libxml2.so (found version "2.7.8") 

This is probably because the /usr/lib dirs are first in the CMake include order. Which makes me think, should conan define CMAKE_INCLUDE_PATH, CMAKE_LIBRARY_PATH to point to the installed packages? Does it do this already? Presumably this would ensure picking up stuff from conan first.

Could this also remove the need for the conan overrides of FindBoost as well?

Cheers

Marco

[1] https://travis-ci.org/DomainDrivenConsulting/dogen/builds/99770552

I've run into a scenario where I have two packages where A depends on B, and both have C as a private dependency (C is a unit-testing framework). In this case, when running conan install on A, it crashes with the following stack-trace:

HEADER ONLY
Requirements
    Boost/1.60.0@lasote/stable
    catch/1.3.0@bjoern/testing
    catch/1.3.0@bjoern/testing
    filesystem/1.0.0@bjoern/testing
    io/1.0.0@bjoern/testing
    zlib/1.2.8@lasote/stable
Traceback (most recent call last):
  File "/Users/bjoern/.pipsi/bin/conan", line 11, in <module>
    sys.exit(run())
  File "/Users/bjoern/.pipsi/virtualenvs/conan/lib/python2.7/site-packages/conans/conan.py", line 6, in run
    main(sys.argv[1:])
  File "/Users/bjoern/.pipsi/virtualenvs/conan/lib/python2.7/site-packages/conans/client/command.py", line 432, in main
    error = command.run(args)
  File "/Users/bjoern/.pipsi/virtualenvs/conan/lib/python2.7/site-packages/conans/client/command.py", line 367, in run
    method(args[0][1:])
  File "/Users/bjoern/.pipsi/virtualenvs/conan/lib/python2.7/site-packages/conans/client/command.py", line 186, in install
    build_mode=args.build)
  File "/Users/bjoern/.pipsi/virtualenvs/conan/lib/python2.7/site-packages/conans/client/manager.py", line 122, in install
    installer.install(deps_graph, build_mode)
  File "/Users/bjoern/.pipsi/virtualenvs/conan/lib/python2.7/site-packages/conans/client/installer.py", line 70, in install
    skip_private_nodes = self._compute_private_nodes(deps_graph, build_mode)
  File "/Users/bjoern/.pipsi/virtualenvs/conan/lib/python2.7/site-packages/conans/client/installer.py", line 110, in _compute_private_nodes
    package_folder = self._paths.package(package_reference)
  File "/Users/bjoern/.pipsi/virtualenvs/conan/lib/python2.7/site-packages/conans/paths.py", line 92, in package
    return normpath(join(self.conan(package_reference.conan), PACKAGES_FOLDER,
  File "/Users/bjoern/.pipsi/virtualenvs/conan/lib/python2.7/site-packages/conans/paths.py", line 45, in conan
    assert isinstance(conan_reference, ConanFileReference)
AssertionError

Now if I remove the "private" for package C from A, everything runs fine. Is this intended behaviour, or a bug?
Btw, I've tried using this as a way to specify dependencies that are used only for development (e.g. for running the unit-tests), but should not be propagated to users of the project. Is this the recommended way to achieve this, or would suggest something else? I could for instance also use an option like --with-tests.

Include variables/data for project dependencies, as:

• Each dependency root folder, so it can be used for FindXXX.cmake
• ...

Hi guys,

Further to your work on adding libxml support, I'm afraid it fails to install for my project in appveyor [1]. It installs a few of the dependencies such as zlib, but then fails on iconv:

Conan winiconv/1.14.0@lasote/stable not found, retrieving from server
WARN: Unable to connect to local=http://localhost:9300
ERROR: All remotes failed
Command exited with code 1

Thanks for your time.

Marco

[1] https://ci.appveyor.com/project/mcraveiro/dogen/build/2.2.27

If user wants to "install" all the requirements for several configurations (gcc, clang, debug, release) at project bootstrap, then change between them just for building. A possible project layout could be:

project
    build
         clang-debug
         gcc-release

Inside each "clang-debug", "gcc-release" folder, a "conanbuildinfo.cmake" (or vsprops, or any other generator), could be created with some option:

$ conan install -s compiler=gcc -s build_type=Release  --output="build/gcc-release"
$ conan install -s compiler=clang -s build_type=Debug  --output="build/clang-debug"

Or maybe:

$ conan install -s compiler=clang -s compiler.version=3.5 -s build_type=Debug $(PROJECT) .

After that, building the project could be:

$ cd build/clang-debug
$ cmake $(PROJECT) -DCMAKE_CXX_COMPILER=clang++-3.5 -DCMAKE_BUILD_TYPE=Debug
$ make -j 4

So the test code and files is not copied to every build/sha folder, but referenced instead. The build folder will live under the test folder, not the root one.

If gcc command does not exist:

Found gcc /bin/sh: gcc: command not found.0
CC and CXX: ,
Default conan.conf settings
os=Linux
arch=x86_64
compiler=gcc
compiler.version=/bin/sh: gcc: command not found.0
build_type=Release

In corperate environments it is frequently the case that internet connection must go trough a proxy server, sometimes even with authentication required.

It would be good if conan would at least support the following proxy scenarios:

1. Access the internet trough a HTTP/HTTPS proxy without authentication
2. Access the internet trough a HTTP/HTTPS proxy with authentication required
3. Access the internet trough a SOCKSv5 proxy (this allows using SSH tunnels)

When I have a conanfile where I remove some settings:

    settings =  {"os": ["Linux", "Macos"],
             "compiler": None,
             "arch": None}

If I use the "CMake" class in build...:

cmake = CMake(self.settings)

It crashes because CMake class makes comparations with settings that I don't have, and its checked that this setting exists:

if self._settings.os == "Windows":

I think we should "cast" to str the settings in this case or something like that.

When writing the YCM generator, I figured it would've been cleaner to be able to register my generator dynamically (i.e. when my conanfile.py is loaded). I wasn't really sure the best way to do this, so I held off in favor of getting good functionality delivered. I think we should be able to do the following:

from conans import ConanFile, Generator

class MyConanFile(ConanFile):
    """
   yada yada yada and stuff
   """
   generators = "mine"

class LocalBuildGenerator(Generator):
   name = "mine"
   output_file = "awesome_build_system.out"

   @property
   def content(self):
      return "By far the coolest build system ever invented"

When we load the conanfile.py, we can scan for any classes inheriting from Generator and register it. This is similar to how we load the ConanFile implementation. This would allow users to create their own pluggable generators that can be reused without having to make a change to conan itself.

Looks like the most recent of the GNU C++ compiler, 5.3, isn't yet supported.

andrew@G75VW:~/Documents/Projects/cddd$ conan install
ERROR: '5.3' is not a valid 'settings.compiler.version' value.
Possible values are ['4.6', '4.7', '4.8', '4.9', '5.0']
andrew@G75VW:~/Documents/Projects/cddd$ uname -a
Linux andrew-G75VW 3.13.0-71-generic #114-Ubuntu SMP Tue Dec 1 02:34:22 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

conans.tools.unzip supports .zip and .tar.*s as far as I can see. It would be nice if .7z would be supported also, as it usually compresses much better.

Boost is 131 MB (.zip) vs 71 MB (.7z) for example (http://sourceforge.net/projects/boost/files/boost/1.60.0/).

Maybe it's related to the anti-virus software, but it's something to look at. I tried launching the installer three times and it didn't work. When shutting down the system, an error message prompted from the installer.

E.g.:

url = 'https://github.com/google/googlemock-conan.git'

Is there a way that only the packages built can be shared and the end user doesn't have access to the code from where it is built . That would be good feature allowing control over if one wants to allow rebuilding of packages on end user side .

Reported by @dimitrikourk in Win7, Firefox 38.3.0 and IE 11, confirmed in Ubuntu Firefox.

Go to https://www.conan.io/source/zlib/1.2.8/lasote/stable -> Issue tracker
Octocat link works, but button doesn't.

Installing 3rd party software in a distro-agnostic way is a pain, since each distro has its own package manager and naming conventions.

For my own dotfiles repo I wrote a cli tool that provides a portable interface to the system package manager, via install_package and update_system commands. The thing works by having a database that maps a generic package name (Say libclang) and a distro name (Say ubuntu/debian) to the specific package name the distro uses. Using that database, you only write install_package libclang in your install scripts, the tool manages to call the correct package manager with the correct package name. See https://github.com/Manu343726/dotfiles#package-management

What I propose is to add such a system to conan, so installing system components would not be a pain.

The first issue that comes to my mind is the mapping database, how it should be stored, updated, shared between users, etc.

Hi Conaneros :-)

I just re-ran Conan from a different machine whilst trying to build Dogen[1] and got the following error:

ERROR: Can't find a 'bzip2/1.0.6@lasote/stable' package for the specified options and settings. 

- Try to build from sources with "--build bzip2" parameter
- If it fails, you could try to contact the package author at 'http://github.com/lasote/conan-bzip2', report your configuration and try to collaborate to support it.

Package configuration:
- Settings: arch=x86_64, build_type=Release, compiler=gcc, compiler.version=5.3, os=Linux
- Options: shared=True

This dependency on bzip2 appears to have came about via boost [2] as I am not requiring it directly.

Cheers

Marco
[1] https://github.com/DomainDrivenConsulting/dogenblob/master/conanfile.txt
[2] https://github.com/DomainDrivenConsulting/dogen/

Now, typical current system package installation could be of the form:

def system_requirements(self):
    self.run("sudo apt-get install ...")

Because typical desktop linux distributions. Is it possible to make this sudo privileges opt-in for systems that do not require it? Doesn't seem a simple task.

• sudo conan install ... definitely not a good idea
• conan install ... --sudo and self.run("apt-get install ... ", sudo=True)

Running the pip install command as described in README.rst fails:

$ pip install conan
Downloading/unpacking conan
  Could not find a version that satisfies the requirement conan (from versions: 0.4.0.dev1, 0.4.0.dev2, 0.4.0.dev3)
Cleaning up...
No distributions matching the version for conan
Storing debug log for failure in /home/svenni/.pip/pip.log

However, requiring a specific version seems to work:

$ pip install conan==0.4.0.dev3

This was tested on Ubuntu 15.10 x64 with pip installed from apt-get.

So heavy CMake users can use conan without having to manually call "conan install ..."

It could be done by creating a pure CMake macro/function that generates a temporary conanfile.txt under the hood with the given parameters to define requirements, settings, etc.

A potential problem is when to use/invoke it, surely not in every build. But should it be done in every cmake project configuration? Probably.

Point out by @trevex, such utility can prove very useful to run commands and capture the output in order to act accordingly.

DRAFT
From my point of view this has to be carefully analysed. I will write down here my thoughts, details and design considerations as a starting point for discussion about this issue.

The conan site on pypi shows version 0.01rc2, but installing actually gives version 0.5.0. This seems to be a pure documentation issue, but should be fixed to avoid confusion.

Operating system: Mint 17 (based on Ubuntu 14.04.3)

I tried to run the tests for the most recent version like this:

#!/usr/bin/env sh
git checkout 1cc3490f67c445a64c5a327df39b261b2b9df558
sudo apt-get install python-dev
sudo pip install -r requirements.txt
sudo pip install -r requirements_server.txt
sudo pip install -r requirements_dev.txt
nosetests .

This is the output:

$ ./run_tests.sh 
HEAD is now at 1cc3490... MIT LICENSED
Reading package lists... Done
Building dependency tree       
Reading state information... Done
python-dev is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 41 not upgraded.
Requirement already satisfied (use --upgrade to upgrade): PyJWT==1.4.0 in /usr/local/lib/python2.7/dist-packages (from -r requirements.txt (line 1))
Requirement already satisfied (use --upgrade to upgrade): cfgparse==1.3 in /usr/local/lib/python2.7/dist-packages (from -r requirements.txt (line 2))
Requirement already satisfied (use --upgrade to upgrade): requests==2.7.0 in /usr/local/lib/python2.7/dist-packages (from -r requirements.txt (line 3))
Requirement already satisfied (use --upgrade to upgrade): colorama==0.3.3 in /usr/local/lib/python2.7/dist-packages (from -r requirements.txt (line 4))
Requirement already satisfied (use --upgrade to upgrade): passlib==1.6.5 in /usr/local/lib/python2.7/dist-packages (from -r requirements.txt (line 5))
Requirement already satisfied (use --upgrade to upgrade): boto==2.38.0 in /usr/local/lib/python2.7/dist-packages (from -r requirements.txt (line 6))
Requirement already satisfied (use --upgrade to upgrade): PyYAML==3.11 in /usr/local/lib/python2.7/dist-packages (from -r requirements.txt (line 7))
Cleaning up...
Requirement already satisfied (use --upgrade to upgrade): gevent==1.0.2 in /usr/local/lib/python2.7/dist-packages (from -r requirements_server.txt (line 2))
Requirement already satisfied (use --upgrade to upgrade): bottle==0.12.8 in /usr/local/lib/python2.7/dist-packages (from -r requirements_server.txt (line 3))
Requirement already satisfied (use --upgrade to upgrade): gunicorn==19.3.0 in /usr/local/lib/python2.7/dist-packages (from -r requirements_server.txt (line 4))
Requirement already satisfied (use --upgrade to upgrade): greenlet>=0.4.7 in /usr/local/lib/python2.7/dist-packages (from gevent==1.0.2->-r requirements_server.txt (line 2))
Cleaning up...
Requirement already satisfied (use --upgrade to upgrade): nose==1.3.7 in /usr/local/lib/python2.7/dist-packages (from -r requirements_dev.txt (line 1))
Requirement already satisfied (use --upgrade to upgrade): nose-parameterized==0.5.0 in /usr/local/lib/python2.7/dist-packages (from -r requirements_dev.txt (line 2))
Requirement already satisfied (use --upgrade to upgrade): mock==1.3.0 in /usr/local/lib/python2.7/dist-packages (from -r requirements_dev.txt (line 3))
Requirement already satisfied (use --upgrade to upgrade): WebTest==2.0.18 in /usr/local/lib/python2.7/dist-packages (from -r requirements_dev.txt (line 4))
Requirement already satisfied (use --upgrade to upgrade): six in /usr/local/lib/python2.7/dist-packages (from WebTest==2.0.18->-r requirements_dev.txt (line 4))
Requirement already satisfied (use --upgrade to upgrade): WebOb>=1.2 in /usr/local/lib/python2.7/dist-packages (from WebTest==2.0.18->-r requirements_dev.txt (line 4))
Requirement already satisfied (use --upgrade to upgrade): waitress>=0.8.5 in /usr/local/lib/python2.7/dist-packages (from WebTest==2.0.18->-r requirements_dev.txt (line 4))
Requirement already satisfied (use --upgrade to upgrade): beautifulsoup4 in /usr/local/lib/python2.7/dist-packages (from WebTest==2.0.18->-r requirements_dev.txt (line 4))
Cleaning up...
E
======================================================================
ERROR: Failure: ImportError (No module named conans.model.conan_file)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/nose/loader.py", line 418, in loadTestsFromName
    addr.filename, addr.module)
  File "/usr/local/lib/python2.7/dist-packages/nose/importer.py", line 47, in importFromPath
    return self.importFromDir(dir_path, fqname)
  File "/usr/local/lib/python2.7/dist-packages/nose/importer.py", line 94, in importFromDir
    mod = load_module(part_fqname, fh, filename, desc)
  File "/home/virtual/dev/conan/conans/__init__.py", line 3, in <module>
    from conans.model.conan_file import ConanFile
ImportError: No module named conans.model.conan_file

----------------------------------------------------------------------
Ran 1 test in 0.001s

FAILED (errors=1)

Am I doing something wrong?

In the same way that cmake is currently supported as a generator it would be awesome to add support for premake 4/5.

In the same way a cmake file includes these lines

...
INCLUDE(conanbuildinfo.cmake)
CONAN_BASIC_SETUP()
...

it would be fantastic if something similar could exist for premake. So within a premake.lua file there could be something akin to:

...
include "conanbuildinfo.lua"
conan_basic_setup()
...

which would include the relevant conan dependencies when doing a build with premake

The password demo works, but demö is rejected:

$ conan upload -r local silicium/0.1@tyroxx/testing
Downloading conanmanifest.txt
[==================================================]                  
Uploading silicium/0.1@tyroxx/testing
Please log in to perform this action. Execute "conan user" command. If you don't have an account sign up here: http://www.conan.io
Please enter a password for "tyroxx" account: 
ERROR: Password contains not allowed symbols

The current mechanism is to define options for it, then use such options to conditionally require (or not) a certain dependency.

It could be easier and more idiomatic if a higher level of abstraction, as specifying a global (dev/production/package) scope for all packages, and packages could use such scope for conditionally defining dependencies.

Requested in #79, but it is not the first time, so I think it is an interesting feature to develop

This has been reported a few times, at least 2 publicly:

• @mcraveiro: #56
• @Klaim: http://boost.2283326.n4.nabble.com/Feedback-boost-conan-binary-packages-td4682377.html

I think this is a common use-case, maybe some helpers can be done to ease this task.

• Let people know more about us and conan's next steps
• Write about new features
• ....

I think with jekyll and github pages are ok (and free).
Blog post from users will be welcome with PRs.

When using conan Boost package, ALL boost libraries are returned in CONAN_LIBS variable. FindXXX.cmake files usually allow to configure which components you want, and only link those components.

It is unlikely that the existing FindBoost will work with the conan packages, as they are "flattened" to include, lib, bin directories, and FindBoost expect some hierachies. Probably a regular Find can be developed that wraps it and filters the libraries to link only the required.

Other possibility is to filter the CONAN_LIBS variable, it has to be checked the UX of this approach, if it fits well to different libraries name patterns (libraries with different names depending on settings), or if it might need some additional helpers to ease the task.

Related to #6

It would be nice if we could install conan via Homebrew on OS X instead of downloading a .pkg.

I have a Python module to separate out some code which would otherwise be duplicated across a bunch of conanfile.pys. It lives next to each conanfile like so:

+ .
|--+ conan_helpers
|  |-- __init__.py
|  \-- ...
\--- conanfile.py

And the conanfile.py imports it as normal:

from conans import ConanFile
from conan_helpers import SomeMixin

class SomeConan(SomeMixin, ConanFile):
    pass

However this fails during conan export with an ImportError:

ImportError: No module named conan_helpers

The workaround at the moment is to add the directory of __file__ to sys.path before the import statement, but it would be nice if I didn't have to do that. ;)

Hi,

i tried to build boost from source on my windows 10 machine (AMD64), and it didn't work.

Log:

G:\Users[name]\programming\projects\mytimer>conan install --build Boost
Requirements
Boost/1.59.0@lasote/stable
WARN: Forced build from source: "Boost/1.59.0@lasote/stable"
Configuring sources in G:\Users\after.conan\data\Boost\1.59.0\lasote\stable\source
Downloading http://sourceforge.net/projects/boost/files/boost/1.59.0/boost_1_59_0.zip/download...
Percent: [########################################] 100.0% of 118.0Mb Done...
Unzipping 416 Mb, this can take a while
Error extract boost_1_59_0/doc/html/images/accumulators/structboost_1_1accumulators_1_1detail_1_1is__tail__variate__feat
ure_3_01tag_1_1tail__variate_3_05c8781b637de300b03d4be7e8c3a6d3b.png
Filename too long

[way more "Filename too long" errors]

Log end

Yay, windows's MAX_PATH!
To work around this everlasting windows problem, I'd like to specify a different source location for packages (or something similar).

Keep up the good work, the c++-community needs you!

Hi,

Many thanks for your work on conan. I just tried logging in to conan with my GitHub profile but it requested an additional password. I may be getting confused, but I was sure this was not a requirement for biicode. Is there any reason for this? Many of the services around GitHub do not require an additional password such as Travis and AppVeyor; it adds a (minor) stumbling block to people who would otherwise log in to the system.

Cheers

Marco

Seeing some failing tests that look like https://gist.github.com/springmeyer/e51c32b1cf32f25a3aee. Wondering if you have any suggestions for what I might be doing wrong. My install method was https://gist.github.com/springmeyer/4f4a4d20e4918c6cd2e1

The use case of conan for intermediate packages development (those having dependencies, and also being under active development, not only just for packaging) is still a bit undefined, as the build has to be supported locally while dev'ing and also when packaging. Reported by @azriel91, with a possible workaround:

https://github.com/azriel91/usbundleloader/blob/a3e64fea3b87566a6fcd0da4b92da9b8119cb560/conanfile.py#L13

This should be addressed more idiomatically. Also, it is important to study and analyze this use case, to know more about long-term development with conan.

It's very common to prepare some env variables before configure, because libraries configure usually don't allow enough parameters for handle the location of their deps headers and libraries.
So the way to do it is settings env variables before calling ./configure
Maybe we could develop a simple helper like the CMake one but for setting those variables.

Now i'm doing:

def generic_env_configure_vars(self):
    """Reusable in any lib with configure!!"""
    libs = 'LIBS="%s"' % " ".join(["-l%s" % lib for lib in self.deps_cpp_info.libs])
    ldflags = 'LDFLAGS="%s"' % " ".join(["-L%s" % lib for lib in self.deps_cpp_info.lib_paths]) 
    archflag = "-m32" if self.settings.arch == "x86" else ""
    cflags = 'CFLAGS="%s %s"' % (archflag, " ".join(self.deps_cpp_info.cflags))
    cpp_flags = 'CPPFLAGS="%s %s"' % (archflag, " ".join(self.deps_cpp_info.cppflags))
    return "%s %s %s %s" % (libs, ldflags, cflags, cpp_flags)

self.run("env %s ./configure" % generic_env_configure_vars())

To the community:
What do you think? Could be useful?

So source code (or other file) downloads in the source() step can be checked for integrity and security.

It could have the form:

tools.download(...)
tools.check_md5(file, "MD5_signature")

Hi

Great job ! So great I would like to use conan with a private local repository. I understand this is still early but is there any more hints on what to do to make a valid production conan server by using gunicorn or bottle directly via uwsgi ?

As in #12, having a package for arch would be great. We can use the ubuntu/debian package as I did with biicode https://github.com/biicode/packages/tree/master/archlinux

Hi,

I have managed to setup my project to use conan and build on windows[1] - thanks very much for the packages you already support, which made it possible. However, one minor stumbling block was lack of support for libxml2. I worked around this problem by installing it from Nuget and then getting CMake to see it. Its not pretty, but it works.

Would it be possible to package libxml2 directly in conan?

Cheers

Marco

[1] Work on a green build is still ongoing, but all dependencies are now located correctly. See https://ci.appveyor.com/project/mcraveiro/dogen/build/2.2.11

Hi,

Thanks very much for all your work with conan. I am using it on Linux (debian testing x64). I've successfully updated my project to use conan[1] but for some reason I'm unable to build using ninja[2]. I'm wondering if I've done something wrong.

The steps to reproduce using my project are as follows (assuming you have libxml dev headers):

$ git clone https://github.com/DomainDrivenConsulting/dogen.git
$ cd dogen/build
$ mkdir output
$ cd output
$ conan install ../..
$ cmake ../.. -G Ninja
$ ninja -j5
<snip>
$ ninja: error: '~/.conan/data/Boost/1.60.0/lasote/stable/package/ebdc9c0c0164b54c29125127c75297f6607946c5/lib/libboost_system.so', needed by 'stage/bin/dogen_utility_spec', missing and no known rule to make it

This error is rather puzzling because I can see boost system in the filesystem and it looks perfectly fine. I can use ninja without conan, but unfortunately I have boost 1.59 on my system, so it's not a perfect comparison. Also, when using GNU make with exactly the same conan settings, the project compiles and runs fine.

The error appears to be some kind of weird interaction between conan, cmake and ninja, but not quite sure who to blame. It could be something as simple as the library path not being passed in all the way to ninja, I guess. When I get more time I will try to create a small program that triggers this behaviour.

In the meantime, any ideas on how to debug this problem are welcome.

Cheers

Marco

[1] http://mcraveiro.blogspot.co.uk/2015/12/nerd-food-dogen-package-management-saga.html
[2] https://ninja-build.org/manual.html

First time it removes the build folder, yay! but then it fails because the folder is not found. I tried in windows.