 |
Fixed the apparent problems in svn rev 9799. More work postponed for 0005881. |
 |
Please consider back-porting the fix into the latest stable release. Otherwise it's not possible to build it, hence package it. ERROR: Failed requirement 'zlib/1.2.11@conan/stable' from 'conanfile.py' ERROR: HTTPSConnectionPool(host='bincrafters.jfrog.io', port=443): Max retries exceeded with url: /artifactory/api/conan/public-conan/v2/conans/zlib/1.2.11/conan/stable/latest (Caused by ReadTimeoutError("HTTPSConnectionPool(host='bincrafters.jfrog.io', port=443): Read timed out. (read timeout=60.0)")) Unable to connect to bincrafters=https://bincrafters.jfrog.io/artifactory/api/conan/public-conan 1. Make sure the remote is reachable or, 2. Disable it by using conan remote disable, Then try again |
|
|
I think I'll not do that. In fact, I don't even plan to use updated recipes for 2.10 release: I'll still use the artefacts built several months ago. The issues in 3rd party libraries can be very subtle, and these artefacts worked for many dev builds with no complaints. Don't want to risk rebuilding everything now. It is sad that recipes do break over time, but that's life. That's the exact reason why we keep binaries in our repo. The code also often stops compiling with new versions of compilers. When I created the conan system, I wanted to simplify developer's life, but make it more complicated. |
|
|
The thing is: packaging into Linux requires everything to be built from source. Since it's a widespread security requirement, and for very good reasons. It's the sole cause why malware doesn't exist. Updating libraries frequently has a very subtle but huge advantage: bugs come little by little, instead all together when you have no option but to update. At the same time the most grave bugs are transient, because those are the ones everyone wants fixed. Meanwhile if something really goes really ugly you can simply keep the previous build. The point is that if something requires constant work, usually it's better to spend a little initial time delegating or automating it. Either automating the generation of recipes, or simply detecting when they no longer work. What do you think we should do in this regard? |
|
|
Ehhm.. Uhm... Stop trying to put TDM into distributions =) |
|
|
No way � |
|
|
I understand this is extra work for you, and I never really expected you to do it. But the thing is I want it done, and I will do it with or without anyone's help. Because I find it much convenient having the game installed as I'm providing it: as a system wide application that can be installed and updated as any other package, continuously built from source without human interaction. I don't expect anyone to have such high standards. Follow me if you can :D |
|
|
Maybe you can just ditch the conan stuff? First make your distribution to provide all the needed dependencies as packages. Then I guess you need to remove this line from our CMake: # find third-party package modules list(PREPEND CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/ThirdParty/cmake_find_package") After that just build, and CMake should find all system packages. There is a catch though: 1) I guess some of the smaller libs are not provided by distribution, so you'll have to get them somehow. 2) Some libs are used in rather extraordinary way. For instance, libjpeg is used with access to "internals". Wrong version of zlib might be dangerous because we hack with zlib internal data structures (alias structs). And default FFmpeg build provides much more than what we use (players don't care though). |
|
|
Thanks. I will consider that. |
|
|
On latest SVN, both issues are resolved: zlib and minizip are consumed as separate packages, thus latest revision of both recipes is used bincrafters remote is no longer used See https://bugs.thedarkmod.com/view.php?id=5881#c14769 |
- Anonymous
