Fix 1394 buildnotes 0.27 #1403
Fix 1394 buildnotes 0.27 #1403
Conversation
|
Thanks @LeoHsiao1 . Hope everything's good with you. Book's coming along well. It'll be finished by the end of the year. If the LGM conference in Rennes happens in 2021, I'll probably go over the text one more time before I pay to print 30 copies to hand out at the conference. Ask your boss to pay for you to attend the conference. It was originally scheduled for May 28-31, 2020. Nobody knows what will happen in 2021. |
|
Thanks. Hope everything's good with you, too. |
|
I have successfully built/tested the new profile cmake/msvc_conan_profiles/msvc2019Release32. |
|
I very much appreciate your work on the Windows compiles, but I am having trouble, partly because I use Python and CMake very infrequently. Trying to install the latest code from Github on a clean PC is not going well. First problems is installing a good enough Python environment under Windows. Any restrictions or special version required? After I installed Python 3.9.0 for all users, forced the installer to add Python to the Path - this is not the default. After half a day, I have been able to get the exiv2lib 32-bit debug version to compile - with something like 6 or seven items compiling, including fortunately exiv2lib, but the rest failing for one reason or another. My 64-bit release profile: conan install .. --build missing --profile msvc2019Release64 tells me that by now eveerything needed is installed All the output log tells me: The system is: "Windows - 10.0.19041 - AMD64" |
|
Arnold (@tester0077). I download python from https://www.python.org/downloads/ and install it in c:\python38 (or 39 or whatever). Keep away from 1 copy python.exe python3.exe 2 start dos with a script like this which I call cmd64.cmd to carefully control your PATH. I always have MinGW/msys2 installed in c:\msys64. You only need this to run the test suite. @echo off
setlocal
set "P="
set "P=%P%C:\Python37\;C:\Python37\Scripts;" # DOS Python3
set "P=%P%c:\Program Files\cmake\bin;" # DOS cmake
set "P=%P%c:\msys64\usr\bin;" # msys2 make, bash etc
set "P=%P%c:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin;"
set "P=%P%c:\Windows\System32;" # windows
set "P=%P%%USERPROFILE%\com;" # my home-made magic
echo %P%
set "PATH=%P%"
set "EXIV2_BINDIR=%USERPROFILE%\gnu\github\exiv2\0.27-maintenance\build\bin"
color 0d
cmd /S /K cd "%EXIV2_BINDIR%\..\.."
color
endlocal |
|
Thank you, Robin. Once I get past that hurdle, I can try to use the same MSVC 2017 IDE as you seems to be using, as it is installed on the target machine. |
|
@tester0077. %USERPROFILE% is something like "c:\Users\rmills" and created by the system. I have the directory on my PATH c:\Users\rmills\com in which I have batch files and executables. Many users will have something equivalent. Please be aware that python3 and bash are only required to run the test suite.
|
|
@tester0077 RE: Conan issue: I've had C:\Python27\ and C:\Python38\ installed for sometime (and included on my system path). As part of building Exiv2 recently I finally got around to removing Python27 from my system path, leaving C:\Python38\Scripts;C:\Python38; (as the first entries in the path). I didn't need to set up any environment (other than ensuring that C:\Python38\Scripts;C:\Python38; were first in my system path). I just used: |
|
Does that mean we should have "one more P" in cmd64.cmd ? set "P=%P%C:\Python37\;C:\Python37\Scripts;%USERPROFILE%\AppData\Roaming\Python\Python37" # DOS Python3This would enable searching both the global and user python script stores. What do you think? |
mergify
bot
dismissed
LeoHsiao1’s stale review
Pull request has been modified.
|
Just re-installing python 39 according to moon6969's recipe. Will carry on when that is finished. |
|
Got Python 3.9 installed. ** Visual Studio 2019 Developer Command Prompt v16.8.2 C:\Users\Arnold\source\repos>conan --version That is where I was stuck before. |
|
@tester0077 . I don't know what's wrong with your conan. I uinstalled my pythons (27, 34 and 37) and removed their remnants I installed python39. And used pip to install conan. It build Exiv2 perfectly, as documented. conan.exe installed perfectly into c:\Python39\Scripts: C:\Python39\Scripts>dir
Volume in drive C has no label.
Volume Serial Number is 0899-EF40
Directory of C:\Python39\Scripts
2020-11-22 16:16 <DIR> .
2020-11-22 16:16 <DIR> ..
2020-11-22 16:16 150,569 bottle.py
2020-11-22 16:15 106,333 chardetect.exe
2020-11-22 16:16 990 conan-script.py
2020-11-22 16:16 74,752 conan.exe
2020-11-22 16:16 1,012 conan_build_info-script.py
2020-11-22 16:16 74,752 conan_build_info.exe
2020-11-22 16:16 1,004 conan_server-script.py
2020-11-22 16:16 74,752 conan_server.exe
2020-11-22 16:15 106,317 distro.exe
2020-11-22 16:13 106,342 easy_install-3.9.exe
2020-11-22 16:13 106,342 easy_install.exe
2020-11-22 16:15 999 futurize-script.py
2020-11-22 16:15 74,752 futurize.exe
2020-11-22 16:15 1,003 pasteurize-script.py
2020-11-22 16:15 74,752 pasteurize.exe
2020-11-22 16:13 106,333 pip.exe
2020-11-22 16:13 106,333 pip3.9.exe
2020-11-22 16:13 106,333 pip3.exe
2020-11-22 16:15 106,327 pygmentize.exe
2020-11-22 16:15 106,323 pyjwt.exe
2020-11-22 16:15 106,319 tqdm.exe
2020-11-22 16:16 <DIR> __pycache__
21 File(s) 1,592,639 bytes
3 Dir(s) 15,587,950,592 bytes free
C:\Python39\Scripts>dir conan.exe
Volume in drive C has no label.
Volume Serial Number is 0899-EF40
Directory of C:\Python39\Scripts
2020-11-22 16:16 74,752 conan.exe
1 File(s) 74,752 bytes
0 Dir(s) 15,587,950,592 bytes free
C:\Python39\Scripts>conan --version
Conan version 1.31.3
C:\Python39\Scripts>python --version
Python 3.9.0
C:\Python39\Scripts>I looked at that having a setting for Python37, Python39 ... I thought about: set PY=Python39
.....The downside is that it's getting "complex" and a little obscure. Verbosity in this case seems better to me. It's not as though this is something you change very often. For example, it's only today that I changed the location of msbuild.exe. That setting's been there for several years without issue. |
|
Yes, batch files can be a real nuisance, aside form their arcane syntax. |
|
@monn6969 I notice that the check box for adding Python to the path was not checked in your screen shot. |
|
Success at last :-) |
|
@tester0077 I'm glad you have this working. And thank you @moon6969 for contributing to this discussion. I only learned about the options When I prepared this PR, I fixed the 32 bit build "not provided" to mention -A Win32. I left the 64bit documentation alone. The default for I will do something concerning this before I merge the PR. |
|
Not sure if this is the 'correct' way to do this, but the changes look good to me. |
|
Thank you for the explanation.
In a way it does make sense, but only in a way.
IMNSHO, for releases from the official source, it would still be very
useful, if not imperative, to have such a 'build/release/progress'
number as well as a way to get it from the compiled code for libraries
and available in the 'about' text for apps.
|
|
Right. I'll wait for somebody to approve this PR. If you discover something wrong with the docs please let me know. If you know how to solve the "Revision ID" issue, you can open a new issue as a "Feature Request" and somebody might undertake the work. |
|
Quite agree with your observation re ideas and their implementation - ideas are a dime a dozen, they say around here :-) As I also don't feel qualified to mess with the existing code & build system for Exiv2, I'd like to at least share my way of getting this done under Windows. All this code is quite recent for me, but from the short time I have used it, it serves my needs. At the top of the main library header, I have the following code: // created & updated by the release pre-build step using Powershell
// & batch scripts to increment the library version build number
// major & minor version numbers require manual updating of
// the file libAboutVersionh.h it contains a line
// #define LIB_ABOUT_DLG_VERSION ("0.0.11")
#include "libVersionh.h"libVersionh.h contains the single line: #define LIB_ABOUT_DLG_VERSION ("0.0.12")The powerShell script I run in the pre-build step of the release version Perhaps this will sow a seed that someone can develop further |
|
I tidied up your earlier "horribly formatted" comment. I hope you like what I have done. We have a Version numbering scheme that's documented in our security policy. https://github.com/Exiv2/exiv2/security/policy Any build (other than a tagged version in GitHub) is a collection of uncertified code. |
|
Thank you for your reformatting. |
|
Thank You everybody for a very vigorous discussion. If anybody spots typos and other stuff in the documents, keep it to yourself! |
|
One of the main reasons for all these questions is my trying to assess the value of using the vcpkg version of Exiv2. Just spent nearly 1 1/2 hrs updating all installed package :-) |
|
We should screen share sometime, Arnold. I build Exiv2 every day on lots of platforms with little effort. I'm curious to understand the difficulties you encounter. I haven't look at the vcpkg stuff. Maybe one day. My priority is user issues and then the book. Some weeks I don't get any work done on the book. However, I want to finish it by the end of the year. I'll find a way. |
|
Now that the conan build works for me, recompiling is no problems and even on slower PCs does not take all that much time. |
|
Working with tools that you seldom use is never fun. And when things don't work as described you have to dig in to find out what's wrong. At least I have documented the Exiv2 build. Lots of project don't bother. When using Visual Studio, I personally prefer to open a solution file with everything ready to go. However the maintenance of these files is a considerable undertaking. For sure conan is better than my home made batch file cmakeBuild.cmd. One of the odd things I have encountered at work is the build being maintained by junior people (college hires and interns). This is an awful idea. When the build is broken, the project grinds to a halt. Same with the documentation. It's important to make it clear and sufficient because the alternative is lots of questions on the forum. Or even worse - people don't use the project because they don't know how to build/test and use the sample applications. I do my best. |
|
You have succeeded in so many way. Much appreciate your support, even if sometimes the the answer is 'no can do' ;-) |
|
FWIW, just had my joy with vcpkg turn to dust. For some reason, the latest 'update' of the packages broke at least a couple of my project builds. |
|
You'll remember I added something to the Exiv2 build to prevent libiconv being used by MSVC builds. I think you've fallen into that same shell hole with other projects! Happy Thanksgiving. Today's the only day in the year when we feel a little homesick for the USA. We loved our 15 years in California. Proud to be a US Citizen. Happy with our decision to go home and to be near the family when we retired. |
|
@tester0077 Arnold. I think there's something wrong with your environment strings and you're picking up the wrong stuff. In the case of Exiv2/CMake/libiconv your issue was being caused by FindIconv.cmake finding libiconv.h and thinking "let's build with that". He's a fool. He'd located a MinGW or Cygwin header. Come link time, the build fails. As the say in the cowboy movies "let's head them off at the pass". I neutered FindIconv.cmake and put something into README.md about this. 884 rmills@rmillsmbp:~/gnu/github/exiv2/0.27-maintenance/cmake $ head FindIconv.cmake
# Distributed under the OSI-approved BSD 3-Clause License. See accompanying
# file Copyright.txt or https://cmake.org/licensing for details.
# This code is disabled for Visual Studio as explained in README.md
if ( NOT MSVC )
#[=======================================================================[.rst:
FindIconv
---------
885 rmills@rmillsmbp:~/gnu/github/exiv2/0.27-maintenance/cmake $ Have a careful look at PATH, LIB, INCLUDE and any environment string that smells of Unix such as mentioning /usr. |
|
Unfortunately for me, this issue is not related specifically to my use of exiv2lib. Some of my other apps also use these and other libraries. I should have been clearer on that point. This is not your problem, but mine ;-) |
|
It's OK. I knew you were talking about other libraries. Be sure to look at your environment strings and also consider the possibility the that package manager is mixing MinGW libraries with MSVC. Doesn't work. Oil and Water. I recorded "Washington Post March" this morning for Thanksgiving. I mentioned this to Miloš. Presumably you've seen that. I bought a Euphonium on 2018-09-29 and have been practicing hard 1-2 hours/day. https://youtu.be/NnwqaRyAWgE
|
|
Happy to hear you have the patience for practising, I definitely don't. |
|
The bigger the company, the slower the response. So, when you let Exiv2 know about something, it gets attention. If you talk to one of the tech giants in Silicon Valley (or Seattle), you'll be lucky to get anything done in less than a year. The politics of a tech giant dictate that the support guy is very reluctant to dare to say anything needs attention. With Exiv2, if it needs attention, it receives it without delay. I don't have a suit managing me. Right. Time for a beer. It's Thanksgiving after all. |
|
Yes, someone else just found a similar issue with another 'triplet' in vcpkg. It might be open source, but it is still a M$ 'baby' |
|
Rats. There's a significant type in the cmd64.bat script. Why can't I revise this branch? I'll open another PR. Git rhymes with shit. |
See #1394. This documentation was revised for v0.27.3 to discuss Visual Studio 2019.
In this PR, I've dealt with your two suggestions which are:
I've also modified the "Ribbon" at the top of the files to provide a link to the Element Chat Server.