Comments (5)
Hi @Drllap
The first question is, where would generating the code make the most sense? In build, source, or generate?
I'd say that generated code is somehow different from the user source, and might belong better to generate()
method, than to source()
method.
The main reason is that source()
must be invariant, and there are lots of chances that generated code is not invariant, and it can change (otherwise why not adding it to the original source and forget about the code generation?). For example changing the version of the tool_requires
might generate different code. This would be handled a bit better in the generate()
that generates code by default inside temporary "build" folders, than operating in the source_folder
.
Also, the temporary build folders like "build" are typically already .gitignored, so no need to track those and make sure that the generated code doesn't slip as changes when committing changes to source.
What am I missing in regards with source_buildenv, why isn't the environment the same in build and source?
It seems there is something missing in the docs. The source_buildenv
only works when building in the local cache. The conan source
command is not expanding dependencies or injecting tool_requires
, the local flow depends on:
conan install
- Activate the generated conanbuild script (.bat/.sh)
conan source
(will find things, because activated by the previous step)
from conan.
@memsharded
This doesn't work either:
def generate(self):
print("GENERATE")
self.run("where openapi-generator")
It appears that the conanbuild.bat
/conanrun.bat
aren't generated until after the generated
method returns
from conan.
The generate()
should do a explicit instantiation of the VirtualBuildEnv
and generate the files before the self.run()
, can you please try that?
from conan.
Not sure what you want me to test but, I tried this:
def generate(self):
print("GENERATE")
ms = VirtualBuildEnv(self)
ms.generate()
# self.run("where openapi-generator")
print("END GENERATE")
Then I run conan install .
and get this:
======== Installing packages ========
openjdk/21.0.1: Already installed! (1 of 2)
openjdk/21.0.1: Creating JAVA_HOME environment variable with : C:\Users\palli\.conan2\p\b\openjdc66756723c25\p
openapi-generator/7.3.0: Already installed! (2 of 2)
WARN: deprecated: Usage of deprecated Conan 1.X features that will be removed in Conan 2.X:
WARN: deprecated: 'env_info' used in: openjdk/21.0.1, openapi-generator/7.3.0
======== Finalizing install (deploy, generators) ========
conanfile.py (open-api-gen/1.0.0): Calling generate()
conanfile.py (open-api-gen/1.0.0): Generators folder: D:\dev\Norbit\conan\generat-fromp-open-api-test\build\generators
GENERATE
END GENERATE
conanfile.py (open-api-gen/1.0.0): Generating aggregated env files
conanfile.py (open-api-gen/1.0.0): Generated aggregated env files: ['conanbuild.bat', 'conanrun.bat']
Install finished successfully
If I uncomment the self.run
line I get this:
======== Installing packages ========
openjdk/21.0.1: Already installed! (1 of 2)
openjdk/21.0.1: Creating JAVA_HOME environment variable with : C:\Users\palli\.conan2\p\b\openjdc66756723c25\p
openapi-generator/7.3.0: Already installed! (2 of 2)
WARN: deprecated: Usage of deprecated Conan 1.X features that will be removed in Conan 2.X:
WARN: deprecated: 'env_info' used in: openapi-generator/7.3.0, openjdk/21.0.1
======== Finalizing install (deploy, generators) ========
conanfile.py (open-api-gen/1.0.0): Calling generate()
conanfile.py (open-api-gen/1.0.0): Generators folder: D:\dev\Norbit\conan\generat-fromp-open-api-test\build\generators
GENERATE
conanfile.py (open-api-gen/1.0.0): RUN: where openapi-generator
INFO: Could not find files for the given pattern(s).
ERROR: conanfile.py (open-api-gen/1.0.0): Error in generate() method, line 52
self.run("where openapi-generator")
ConanException: Error 1 while executing
so the *.bat
files aren't generated. Maybe this has something to do with the deprecation warning?
from conan.
You are right, there is a small detail that when doing the job in generate()
, the conanbuild
default environment aggregator is not there. I have been able to write a successful test as:
def test_generate_buildenv(self, client):
c = client
pkg = textwrap.dedent("""
from conan import ConanFile
from conan.tools.env import VirtualBuildEnv
import platform
class Pkg(ConanFile):
name = "pkg"
version = "0.1"
tool_requires = "tool/0.1"
def generate(self):
VirtualBuildEnv(self).generate()
cmd = "mytool.bat" if platform.system() == "Windows" else "mytool.sh"
self.run(cmd, env="conanbuildenv")
""")
c.save({"conanfile.py": pkg})
c.run("create . -vv")
assert "MY-TOOL! tool/0.1" in c.out
c.run("install .") # to generate conanbuild script first, so it is available
assert "MY-TOOL! tool/0.1" in c.out
The solution is to do the env="conanbuildenv"
to specify the generated environment file.
from conan.
Related Issues (20)
- [question] conan info --graph replacement? HOT 2
- [question] Conan1 vs Conan2 package id compatibility + possibility of Artifactory hash collision? HOT 2
- Conan2 Config Uninstall HOT 3
- [question] test_package does not respect dependency includes/libs HOT 2
- [question] How to pass resource file path to consumer? HOT 3
- [feature] Extend revision_mode 'scm_folder' to allow for multiple folders HOT 6
- [bug] Large conan package gets downloaded to a wrong subfolder in windows HOT 5
- [question] Is Python inheritance allowed or not? HOT 2
- [question] core.cache:storage_path + Docker HOT 2
- [question] How to implement a validation in the best way? HOT 4
- [question] LD_LIBRARY_PATH and DYLD_LIBRARY_PATH are not added in CMakePresets.json HOT 4
- [suggestion] Access properties of profile's tool requirements in [conf] section HOT 7
- [question] Is IMPORTED_LOCATION missing for conan_package_library_targets? HOT 4
- [bug] yasm/1.3.0 doesn't compile with MSVC in release HOT 4
- [question] How to support conanfile.py in a subdirectory, using Bazel HOT 2
- [bug] generated BUILD.bazel file does not import dll when shared=True for some packages
- [question] Access Resource file in cmake module HOT 2
- [bug] Conan install/graph explain don't find package because they don't filter based on settings/options before selecting package candidate HOT 1
- [question] Header library automatic downstream header propagation HOT 4
- [bug] `conan.tools.files.copy()` fails silently. HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from conan.