Jump to content

Recommended Posts

I recently discovered the conan-style install, but I have difficulties with using it. I started  with the quickstart example. My conanfile.txt contains

[requires]                               
SystemC/2.3.3@minres/stable              
SystemCVerification/2.0.0a@minres/stable
gtest/1.8.1@bincrafters/stable           
flex/2.6.4@bincrafters/stable            
qt5/5.13.0@bincrafters/stable       

  and

$ conan remote list
conan-center: https://conan.bintray.com [Verify SSL: True]
minres: https://api.bintray.com/conan/minres/conan-repo [Verify SSL: True]
flex: https://github.com/bincrafters/conan-flex [Verify SSL: True]
qt5: https://github.com/bincrafters/conan-qt [Verify SSL: True]
gtest: https://github.com/bincrafters/conan-gtest [Verify SSL: True]

Shall I do anything else? With this, I receive the  message

$ sudo conan install .. --build=missing
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++
compiler.version=7
os=Linux
os_build=Linux
[options]
[build_requires]
[env]

WARN: SystemCVerification/2.0.0a@minres/stable requirement SystemC/2.3.2@minres/stable overridden by your conanfile to SystemC/2.3.3@minres/stable
flex/2.6.4@bincrafters/stable: Not found in local cache, looking in remotes...
flex/2.6.4@bincrafters/stable: Trying with 'conan-center'...
flex/2.6.4@bincrafters/stable: Trying with 'minres'...
flex/2.6.4@bincrafters/stable: Trying with 'flex'...
flex/2.6.4@bincrafters/stable: Trying with 'qt5'...
flex/2.6.4@bincrafters/stable: Trying with 'gtest'...
ERROR: Unable to find 'flex/2.6.4@bincrafters/stable' in remotes

I.e. gtest can be installed with conan, the rest not ; the same happens with the command line

$ conan install qt/5.13.0@bincrafters/stable

Do I wrong something?

BTW: I receive the message

WARN: SystemCVerification/2.0.0a@minres/stable requirement SystemC/2.3.2@minres/stable overridden by your conanfile to SystemC/2.3.3@minres/stable

Which is true, I really changed in the conanfile.txt to 2.3.3. Maybe SystemCVerification should be updated.

Also, I wanted to install TLM. Does it have similar conan recipe and store?

 

 

Share this post


Link to post
Share on other sites

You should use

SystemCVerification/2.0.1@minres/stable

instead of 2.0.0a. As these are binary packages (with source) there are version dependencies.

TLM2.0 is part of SystemC so it comes automatically with the SystemC package.

Actually I might want to start with:

git clone https://github.com/Minres/SystemC-Quickstart
cd SystemC-Quickstart/
mkdir build
cd build/
cmake ..
make

This is all you need to start developing based on SystemC. More details to be found in the README.md

Share this post


Link to post
Share on other sites

Well, up to that point is everything fine. In the next step I attempt to add gtest using line

gtest/1.8.1@bincrafters/stable

The message is
 

$ make
[ 50%] Linking CXX executable bin/TransactionExample
/usr/bin/ld: cannot find -lgmock_maind
/usr/bin/ld: cannot find -lgmockd
/usr/bin/ld: cannot find -lgtestd
collect2: error: ld returned 1 exit status
CMakeFiles/TransactionExample.dir/build.make:94: recipe for target 'bin/TransactionExample' failed
make[2]: *** [bin/TransactionExample] Error 1
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/TransactionExample.dir/all' failed
make[1]: *** [CMakeFiles/TransactionExample.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2

well, I understood that gmock is missing, but AFAIN since 1.8.0 it should come with gtest. In addition, the dependencies are about something similar. No difference if I use conan; somehow gtest depencence is missed.

 

Share this post


Link to post
Share on other sites

Actually you need to add the library dirs to your cmake target liek this:

link_directories(${CONAN_LIB_DIRS_GTEST})
add_executable(TransactionExample main.cpp)
target_link_libraries(TransactionExample ${CONAN_LIBS})

Since the CMake setup in the example project is not 'conan only' things are a bit different (it can also be used with SYSTEMC_HOME env variable). If you rely entirely on conan you could simplify the CMakeLists.txt to

cmake_minimum_required(VERSION 3.3)
set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} ${CMAKE_CURRENT_SOURCE_DIR}/cmake)

include(Conan)

project(TransactionExample CXX)

setup_conan()
conan_set_std()
conan_global_flags()

add_executable(TransactionExample main.cpp)
conan_target_link_libraries(TransactionExample)

I updated the README in the Quickstart Project accordingly

Share this post


Link to post
Share on other sites

First of all, thank you for the quick and effective help.

To be frank, I found the conan approach attractive because otherwise it is rather tedious to start up a new project; I guess the same feeling triggered you to assemble and publish the package. My naive idea was that both myself when I assemble a new working environment as well as my users installing the package on their own system, will set up the system using conan (i.e. we do not need to hunt down the individual packages, sometimes finding version compatibility problems), and after that we can rely on the CMake environment as before. That is I do not need conan in the followings, but I need it heavily when I start up. So, the ideal would be not a "CMake only" (where I DO NEED to deal with the packages and their dependencies), and not a "conan only" (where I come out from the normal CMake environment) handling. I would prefer the combined way. Maybe you should have a look at the the package and devote a couple of sentences in the readme file to this aspect.

I think that what you call "conan-only"  version, meets my needs (except that in the section "Build the project (it will download the needed libraries) and run it:" after

cmake ..

a

make

shall also be inserted). I think it is a very useful contribution, especially for the beginners and non-professional developers. I think, however, that every single development must start immediately at the very beginning with testing; so it would be great to complete this contribution with a testing example.

I would suggest to make one more update. In the conanfile.txt you say

[options]
SystemC:stdcxx=14

and in CMakeLists.txt

set(CMAKE_CXX_STANDARD 14)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF)

find_package(SystemC REQUIRED)
if(SystemC_FOUND)

As the SystemC (AFAIK) defaults standard to '98 and it can be set independently; it may make confusion if you use this makefile with another sources, compiled independently (library version mismatch). In my own sources I use

set (CMAKE_CXX_STANDARD ${SystemC_CXX_STANDARD} CACHE STRING
     "C++ standard to build all targets. Supported values are 98, 11, and 14.")

of course after

find_package(SystemCLanguage CONFIG REQUIRED)

I think this can prevent some potential questions and bugs. (BTW: SystemC or SystemClanguage is the preferred utilization)

 

Share this post


Link to post
Share on other sites

Actually in my experience mixing various C++ standard levels is not advisable as they imply changes in libstdc++ which may lead to all sort of issues. So my general recomendation is to have the same setting in all libraries. Hence this general apporach. And conan_set_std()

conan_set_std()

will set the standard level to C++14 in this example.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×