Open himansu2906 opened 2 years ago
Hi @himansu2906
Can you please try sharing your conanfile.py and your CMakeLists.txt?
Another thing to try is to start with a "hello world" simple package, created with conan new hello/0.1 -m=cmake_lib
, and see if you are able to build with that compiler. It is possible that such compiler has something specific (like gcc 3.4 is really old and the Conan toolchain is producing some incompatible flag, because it is designed and tested with more modern compilers.
Also, please, do not share the output as images, but copy and paste the whole output as text (Github has utilities to hide it, so it doesn't clutter the whole issue), not trimming it, but the whole command output. Thanks!
Ok, I start to understand where the issues could be. Let me explain them:
set (CMAKE_TOOLCHAIN_FILE=~/tricore-gcc.cmake)
set (CMAKE_C_COMPILER "C:/HighTec/TriCore_v3_4_7_3/bin/tricore-gcc.exe")
Shoudn't be in your CMakeLists.txt. This is not related to Conan, but good CMake practices
tricore-gcc.cmake
toolchain is necessary to build, then you can pass it your profile, defining it as a conf
tools.cmake.cmaketoolchain:user_toolchain=tricore-gcc.cmake
file. The idea is that it is something external to the build files and the packages. Some builds/binaries will be using that profile, and some builds can be using a different compilers, but the configuration for compiler, etc, should not be hardcoded in recipes or CMakeLists.txt, but external, as configuration (in this case, Conan profile files is the recommended way)package_info()
is useless. That is information for the consumers, about your own package, not about setting the environment for yourself.As a general recommendation, if you haven't yet I would recommended learning first a bit of the basics. Creating simple Conan packages, for different variants, but for mainstream, native compilers like Visual Studio or regular gcc. Reuse those packages. Use profile files to define configurations, etc. Then when you grasp the basics, you can then start more advanced stuff, as defining other non mainstream compilers, etc. If you like videos, then this free course might help a bit: https://academy.jfrog.com/path/conan
Is it possible to get this tricore-gcc.exe compiler from somewhere to be able to test it?
A couple of further notes:
generators = "cmake_find_package_multi", "gcc", "txt"
are useles, you shouldn't be using them here. If anything, try with the new CMakeDeps
, when you have dependencies (not this case).package_info()
can be removed, according to the above comments.@memsharded : do you have any update for me on the issue?
I am trying to reproduce this, but due to not knowing about this specific compiler, it is being very complex.
I would need to reproduce, first the basic CMake example, without Conan:
CMakeLists.txt
that builds the very minimal executable from a very simple source code.Then, for Conan, I would need specification of the full profile, for example:
os
(of the target system, is it Linux?)arch
(the architecture of the target system)Hi @himansu2906
I have managed to make it work, indeed the toolchain was the piece that I was missing. Find attached a working example: tricore-example.zip
Need to:
tricore
profile, need to specify the full path to the tricore-gcc.cmake toolchain instead of tools.cmake.cmaketoolchain:user_toolchain=["<path-to-toolchain>/tricore-gcc.cmake"]
(there could be ways to make this relative, using jinja syntax, but lets keep it simple.[buildenv]
section in the profile to add it to the path with the PATH=+(path)<path-to-tricore>
syntax, and also I did the same to put Mingw in the path. If you have them, no need to do thisconan create . -pr=tricore
That should run the creation of a package (a library), and also the "consuming" and testing of that library by an executable application inside the test_package
folder.
The changes I had to to are:
"3.4"
to the possible settings.yml
(this file is in the Conan cache, in your <userhome>/.conan
(this file can be managed in production with conan config install
, so it is not necessary to do this manual change)conan_toolchain.cmake
was the flags. I discarded them from the conan toolchain with:
def generate(self):
tc = CMakeToolchain(self)
tc.blocks.remove("arch_flags")
tc.generate()
generators = "VirtualBuildEnv"
in the recipe, to make sure the environment (from my [buildenv]
section) is injected correctly.test_package/conanfile.py
the existence of the file:
def test(self):
# we cannot run it
cmd = os.path.join(self.cpp.build.bindirs[0], "example.elf")
# Just check its existence
assert os.path.isfile(cmd)
Just a note, the profile
that is being passed with -pr=tricore
should be the "host" profile (the one the binary will run). As it has the ELF extension, maybe it shouldnt be Windows
, but Linux
?
Please try it and let me know. Thanks!
Hi @memsharded,
do you have any update on above question regarding no ".a files" being generated in package folder.
yes, the build executed by the build()
method happens in a "build" folder in the cache.
The package()
method has the responsibility of copying the desired package artifacts from the "build" folder to the "package" folder. This can be done in different ways:
CMake()
install method cmake.install()
in the package()
method, if the CMakeLists.txt contains correct install instructionsfrom conan.tools.files import copy
and explicit copy(self, ...)
calls inside package()
method.Hello @memsharded , Sorry for hijacking your issue. We use the same compiler , Do you see any potential issues if we define the profiles like this: `target_host=C:/hightec_ifx/bin/tricore standalone_toolchain=C:/hightec_ifx/ cc_compiler=tricore-gcc
[settings] os=RTAOS arch=tc39xx arch_build=x86_64 compiler=tricore-gcc build_type=Release
[env] PATH=[$standalone_toolchain/bin] CC=$target_host-gcc.exe LD=$target_host-gcc.exe AR=$target_host-ar.exe AS=$target_host-as RANLIB=$target_host-ranlib STRIP=$target_host-strip CFLAGS=-O2 -g -W -Wall -Wcast-align -Wcast-qual -Wmissing-noreturn -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wfloat-equal -Wredundant-decls -Wstrict-prototypes -Wundef -Wunsuffixed-float-constants -mversion-info -Wmissing-declarations -Winline -Werror-implicit-function-declaration -Wno-bad-function-cast -Wsign-compare -finline -mcpu=tc39xx -maligned-data-sections -fmessage-length=0 -fno-builtin-memcpy -fno-builtin-memcmp -fno-builtin-memset -fno-builtin-strlen -fno-common LDFLAGS=-lgcc -mcpu=tc39xx -mfixed-sda -Wl,-r -nostdlib -Wl,--cref -Wl,-no-demangle,-demangle=none -Wl,--extmap=a -ferror-numbers
[conf] tools.cmake.cmaketoolchain:generator=MinGW Makefiles`
One more additional question would be : How are profiles handling absolute and relative linking ? Thanks in advance for answering my question. Its probably even a cmake question as LDFLAGS is an environment variable in cmake.
I don't see any apparent issue, if it works for you, besides using the legacy [env]
management instead of the new integrations, that you should use to be 2.0 ready:
[buildenv]
and VirtualBuildEnv
conf
like tools.build:cflags
. In this case if only using this compiler, the environment [buildenv]
could work.Check https://docs.conan.io/en/latest/reference/conanfile/tools.html for more info
It so far works for me . Actually sometime back in another issue, I requested to update the documentation for build env and runtime env which was mentioned as new feature in 2.0. See here: https://github.com/conan-io/conan/issues/11499#issuecomment-1165447155 . And I still cannot find it. Perhaps I am missing checking , could you please be kind to forward me the exact link ?
Yes, we are going to add some more docs for exactly this in 1.52 release soon.
Sorry to bother you again : One more additional question would be : How are profiles handling absolute and relative linking ? Thanks in advance for answering my question. Its probably even a cmake question as LDFLAGS is an environment variable in cmake. We have both absolute linking and relative linking as we have execute in place microcontroller.
How are profiles handling absolute and relative linking ? Thanks in advance for answering my question. Its probably even a cmake question as LDFLAGS is an environment variable in cmake. We have both absolute linking and relative linking as we have execute in place microcontroller.
This is not something handled by profiles, it depends on compiler, build systems, etc. Note that CMake does not necessarily always listen to env-vars (maybe only with Makefiles generators?). You can define user conf
if you need it, or maybe it is something that you want to create custom settings to model it, and then pass that setting to your build scripts. But Conan doesn't have anything built-in for it.
Hello All,
I am new to conan and currently trying to create library package and I am using gcc compiler.
whenever I am trying to create package it is giving following error
but if I am building this library with cmake command, it is building perfectly fine.
I am not able to set cross compile setting for with Conan.
if anyone can guild how can cross compile with with Conan.