<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace;font-size:x-small;color:#073763">I agree, something appears to have changed in the most recent version of cmake.</div><div class="gmail_default" style="font-family:monospace,monospace;font-size:x-small;color:#073763"><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:x-small;color:#073763">My build directory has always been added to the source directory. I think you've questioned that before but Thomas is the one that told me to do it that way and he came to the rescue and said it's fine and I think it's how he does it. cmake is what fails. I can try moving the build directory outside of the source with the : in the directory name for the source but not the build but I'm pretty tired of compiling it right now:-) It's not a great long term option since I compile fairly often and have to clean up the old versions. That would double my clean up.</div><div class="gmail_default" style="font-family:monospace,monospace;font-size:x-small;color:#073763"><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:x-small;color:#073763">I'm back to running a fresh build from the master so I'm happy.</div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><font color="#073763" face="monospace, monospace" size="1"><br></font></div><div dir="ltr"><font color="#073763" face="monospace, monospace" size="1">----<br>Brendan Coupe</font><br></div></div></div></div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Nov 12, 2018 at 2:55 PM Jack Ostroff <<a href="mailto:ostroffjh@aya.yale.edu">ostroffjh@aya.yale.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2018.11.12 16:27, Jack wrote:<br>
> OK, I've now been able to duplicate it - it does NOT happen if the  <br>
> build directory is not under the source directory.  It does happen if  <br>
> the build directory is under the source directory.  I still haven't  <br>
> figured out exactly what is failing, but I finally do see the  <br>
> relevant files left under CMakeFiles/CMakeTmp.<br>
Got it (sort of).  the relevant error occurs when cmake runs gmake  <br>
(symlink from make) on the Makefile it creates to compile the cxx  <br>
program which tests for the presence of libIcal.<br>
<br>
gmake[2]: Entering directory  <br>
'/local/data/jack/KDE/KMM/kmymoney-MASTER-2018.11.12-13:15:37/build/CMakeFiles/CMakeTmp'<br>
CMakeFiles/cmTC_98fb0.dir/build.make:64: *** target pattern contains no  <br>
'%'.  Stop.<br>
<br>
A bit of googling says that error is perhaps not well worded, but does  <br>
occur because of the colon in the path name in line 64 of that  <br>
build.make file (buried under CMakeTmp.)  The colon confuses the make  <br>
about what rule it is trying to deal with on that line.<br>
<br>
Because your script has worked for years, I suspect either something  <br>
may have changed in a recent version of make, or perhaps you have moved  <br>
the build dir from outside to under the src dir?<br>
<br>
> On 2018.11.12 15:24, Brendan Coupe wrote:<br>
>> I figured it out. After trying many manual and script based builds I  <br>
>> started to see a pattern. It only failed to build when it was in the  <br>
>> directory that my script created with a date/time stamp. I've been  <br>
>> using this script for 10+ years without a problem. The download  <br>
>> directory names looked like this:<br>
>> <br>
>> kmymoney-MASTER-2018.11.12-13:15:37<br>
>> <br>
>> Simply changing the : to . solve the cmake problem.<br>
>> <br>
>> kmymoney-MASTER-2018.11.12-13.15.37<br>
>> <br>
>> Sometimes I really hate computers.<br>
>> <br>
>> Thanks for all of your help Jack.<br>
>> <br>
>> ----<br>
>> Brendan Coupe<br>
>> <br>
>> <br>
>> On Sun, Nov 11, 2018 at 4:53 PM Jack  <br>
>> <<a href="mailto:ostroffjh@users.sourceforge.net" target="_blank">ostroffjh@users.sourceforge.net</a>><br>
>> wrote:<br>
>> <br>
>> > On 2018.11.10 20:25, Brendan Coupe wrote:<br>
>> > > I'm not sure I explained what I've tried well enough for you to<br>
>> > > understand. While I normally use compile and install scripts  <br>
>> that I<br>
>> > > wrote a long time ago (used with cvs and svn) I tried compiling  <br>
>> from<br>
>> > > the official tar file for the recently released 5.0.2. It worked  <br>
>> fine<br>
>> > > on both my older upgraded (F28 to F29) and on my new clean F29<br>
>> > > install.<br>
>> > ><br>
>> > > I think this means my systems are fine.<br>
>> > ><br>
>> > > I just manually downloaded both the master and 5.0 branches from  <br>
>> the<br>
>> > > KMM git web site. Both compile fine. When I run the git clone  <br>
>> command<br>
>> > > that is in my script and then run cmake, it fails just like I<br>
>> > > mentioned in my original email. Except for how I download the  <br>
>> source<br>
>> > > code, I'm running the exact same steps that I use for the  <br>
>> manually<br>
>> > > downloaded zip versions of KMM (5.0.2 release, 5.0 branch &  <br>
>> master<br>
>> > > branch) and they all succeed.<br>
>> > ><br>
>> > > When I compare the size of the source code directories, all of  <br>
>> the<br>
>> > > zip files result in about 21k of source files. The git downloaded<br>
>> > > folder is about 70k. I suspect git is the problem and it may not  <br>
>> be<br>
>> > > related to F29 since I started having problems compiling from  <br>
>> source<br>
>> > > several weeks before I upgraded to F29. There is a .git  <br>
>> directory in<br>
>> > > the git clone directory that is about 49k so it's probably the<br>
>> > > difference.<br>
>> > You could do a diff -r comparing the source dir from the zip/tar  <br>
>> and<br>
>> > the source downloaded from git.  The only difference (off the top  <br>
>> of my<br>
>> > head) should be the presence of the .git directory, as you  <br>
>> suspect.  If<br>
>> > there are other differences, see what they are.  Be sure that the  <br>
>> zip<br>
>> > and git are both at the same commit of the same branch, which I  <br>
>> think<br>
>> > you are already doing correctly.<br>
>> ><br>
>> > > The git command that worked until 4 to 6 weeks ago is:<br>
>> > ><br>
>> > > git clone git://<a href="http://anongit.kde.org/kmymoney" rel="noreferrer" target="_blank">anongit.kde.org/kmymoney</a> $BRANCH $KMMDIR<br>
>> > ><br>
>> > > Is this correct?<br>
>> > I don't think so.  I don't think (but am not absolutely certain)  <br>
>> that<br>
>> > you shouldn't specify the branch.  Do the git clone first  <br>
>> (specifying<br>
>> > the directory is ok) and then do "git checkout branch" to switch.<br>
>> > Looking at "git clone --help" however, you could also do "git  <br>
>> clone URL<br>
>> > --branch $BRANCH" to not need to do the checkout.<br>
>> > ><br>
>> > I'm also still curious whether there is any hint of what went  <br>
>> wrong in<br>
>> > those files or folder after the cmake fails.<br>
>> ><br>
>> > In theory, the git and tarball/zip of the same branch/commit  <br>
>> should be<br>
>> > identical, so the issue may be either that the git clone does have  <br>
>> some<br>
>> > difference, or that cmake is possibly aware it is running in a git<br>
>> > repository and doing something different.  (I think the latter is<br>
>> > unlikely, but I'm grabbing at straws here.)<br>
>> ><br>
>> > Jack<br>
>> > > ----<br>
>> > > Brendan Coupe<br>
>> > ><br>
>> > ><br>
>> > > On Sat, Nov 10, 2018 at 3:44 PM Jack  <br>
>> <<a href="mailto:ostroffjh@users.sourceforge.net" target="_blank">ostroffjh@users.sourceforge.net</a>><br>
>> > > wrote:<br>
>> > ><br>
>> > > > On 2018.11.10 13:35, Brendan Coupe wrote:<br>
>> > > > > I downloaded the source for 5.0.2 and compiled it without any<br>
>> > > > > problems. I<br>
>> > > > > tried the 5.0 and master branches again and they failed on  <br>
>> iCal<br>
>> > > again.<br>
>> > > > > Seems that there is something off with the source on git???<br>
>> > > > I doubt there is actually anything "wrong."  I suspect some bad<br>
>> > > > interaction caused by F29 using a newer version of some tool.<br>
>> > > Again -<br>
>> > > > right after you get the failure, have you checked the files and<br>
>> > > > directory I suggested?   I'll also try compiling from git head  <br>
>> with<br>
>> > > gcc<br>
>> > > > 8.<br>
>> > > ><br>
>> > > > ><br>
>> > > > > ----<br>
>> > > > > Brendan Coupe<br>
>> > > > ><br>
>> > > > ><br>
>> > > > > On Thu, Nov 8, 2018 at 11:44 AM Jack<br>
>> > > <<a href="mailto:ostroffjh@users.sourceforge.net" target="_blank">ostroffjh@users.sourceforge.net</a>><br>
>> > > > > wrote:<br>
>> > > > ><br>
>> > > > > > I am able to run cmake (3.11.4) with gcc 8.2.0, with either<br>
>> > > make or<br>
>> > > > > > ninja, with no errors.   In your build directory, is there<br>
>> > > anything<br>
>> > > > > > useful in CMakeFiles/CMakeOutput.log or CMakeError.log?   <br>
>> Also<br>
>> > > look<br>
>> > > > > in<br>
>> > > > > > CMakeTmp/<br>
>> > > > > ><br>
>> > > > > > Another possible approach:   cmake --all-other-parameters<br>
>> > > > > >  <br>
>> --trace-source=/path/to/source/cmake/modules/FindLinical.cmake<br>
>> > > > > > --debug-trycompile /path/to/source<br>
>> > > > > > Then see if anything useful shows up in the above places.<br>
>> > > > > ><br>
>> > > > > > On 2018.11.07 20:29, Brendan Coupe wrote:<br>
>> > > > > > > Fedora got 5.0.1 to compile so there must be some hope:-)<br>
>> > > > > > ><br>
>> > > > > > > I added the --debug-output option to cmake. The output  <br>
>> from<br>
>> > > just<br>
>> > > > > after<br>
>> > > > > > > the weboob errors are copied below:<br>
>> > > > > > ><br>
>> > > > > > ><br>
>> > > > > ><br>
>> > > > ><br>
>> > > ><br>
>> > ><br>
>> >  <br>
>> ===========================================================================<br>
>> > > > > > ><br>
>> > > > > > > CMake Warning (dev) at cmake/modules/FindLibical.cmake:59<br>
>> > > > > (try_run):<br>
>> > > > > > >   Policy CMP0066 is not set: Honor per-config flags in<br>
>> > > > > try_compile()<br>
>> > > > > > >   source-file signature.  Run "cmake --help-policy  <br>
>> CMP0066"<br>
>> > > for<br>
>> > > > > policy<br>
>> > > > > > >   details.  Use the cmake_policy command to set the  <br>
>> policy and<br>
>> > > > > > > suppress this<br>
>> > > > > > >   warning.<br>
>> > > > > > ><br>
>> > > > > > >   For compatibility with older versions of CMake,  <br>
>> try_compile<br>
>> > > is<br>
>> > > > > not<br>
>> > > > > > > honoring<br>
>> > > > > > >   caller config-specific compiler flags (e.g.<br>
>> > > > > CMAKE_C_FLAGS_DEBUG)<br>
>> > > > > > > in the<br>
>> > > > > > >   test project.<br>
>> > > > > > > Call Stack (most recent call first):<br>
>> > > > > > >   CMakeLists.txt:242 (find_package)<br>
>> > > > > > > This warning is for project developers.  Use -Wno-dev to<br>
>> > > suppress<br>
>> > > > > it.<br>
>> > > > > > ><br>
>> > > > > > >    Called from: [2]<br>
>> > > > > > ><br>
>> > > > > ><br>
>> > > > ><br>
>> > > ><br>
>> > ><br>
>> >  <br>
>> /usr/local/src/kmm/kmymoney-5.0-2018.11.07-18:23:12/cmake/modules/FindLibical.cmake<br>
>> > > > > > >                 [1]<br>
>> > > > > > ><br>
>> > >  <br>
>> /usr/local/src/kmm/kmymoney-5.0-2018.11.07-18:23:12/CMakeLists.txt<br>
>> > > > > > > CMake Warning (dev) at cmake/modules/FindLibical.cmake:59<br>
>> > > > > (try_run):<br>
>> > > > > > >   Policy CMP0056 is not set: Honor link flags in  <br>
>> try_compile()<br>
>> > > > > > > source-file<br>
>> > > > > > >   signature.  Run "cmake --help-policy CMP0056" for  <br>
>> policy<br>
>> > > > > details.<br>
>> > > > > > > Use the<br>
>> > > > > > >   cmake_policy command to set the policy and suppress  <br>
>> this<br>
>> > > > > warning.<br>
>> > > > > > ><br>
>> > > > > > >   For compatibility with older versions of CMake,  <br>
>> try_compile<br>
>> > > is<br>
>> > > > > not<br>
>> > > > > > > honoring<br>
>> > > > > > >   caller link flags (e.g.  CMAKE_EXE_LINKER_FLAGS) in  <br>
>> the test<br>
>> > > > > > > project.<br>
>> > > > > > > Call Stack (most recent call first):<br>
>> > > > > > >   CMakeLists.txt:242 (find_package)<br>
>> > > > > > > This warning is for project developers.  Use -Wno-dev to<br>
>> > > suppress<br>
>> > > > > it.<br>
>> > > > > > ><br>
>> > > > > > >    Called from: [2]<br>
>> > > > > > ><br>
>> > > > > ><br>
>> > > > ><br>
>> > > ><br>
>> > ><br>
>> >  <br>
>> /usr/local/src/kmm/kmymoney-5.0-2018.11.07-18:23:12/cmake/modules/FindLibical.cmake<br>
>> > > > > > >                 [1]<br>
>> > > > > > ><br>
>> > >  <br>
>> /usr/local/src/kmm/kmymoney-5.0-2018.11.07-18:23:12/CMakeLists.txt<br>
>> > > > > > > CMake Warning (dev) at cmake/modules/FindLibical.cmake:59<br>
>> > > > > (try_run):<br>
>> > > > > > >   Policy CMP0067 is not set: Honor language standard in<br>
>> > > > > try_compile()<br>
>> > > > > > >   source-file signature.  Run "cmake --help-policy  <br>
>> CMP0067"<br>
>> > > for<br>
>> > > > > policy<br>
>> > > > > > >   details.  Use the cmake_policy command to set the  <br>
>> policy and<br>
>> > > > > > > suppress this<br>
>> > > > > > >   warning.<br>
>> > > > > > ><br>
>> > > > > > >   For compatibility with older versions of CMake,  <br>
>> try_compile<br>
>> > > is<br>
>> > > > > not<br>
>> > > > > > > honoring<br>
>> > > > > > >   language standard variables in the test project:<br>
>> > > > > > ><br>
>> > > > > > >     CMAKE_CXX_STANDARD<br>
>> > > > > > >     CMAKE_CXX_STANDARD_REQUIRED<br>
>> > > > > > >     CMAKE_CXX_EXTENSIONS<br>
>> > > > > > ><br>
>> > > > > > > Call Stack (most recent call first):<br>
>> > > > > > >   CMakeLists.txt:242 (find_package)<br>
>> > > > > > > This warning is for project developers.  Use -Wno-dev to<br>
>> > > suppress<br>
>> > > > > it.<br>
>> > > > > > ><br>
>> > > > > > >    Called from: [2]<br>
>> > > > > > ><br>
>> > > > > ><br>
>> > > > ><br>
>> > > ><br>
>> > ><br>
>> >  <br>
>> /usr/local/src/kmm/kmymoney-5.0-2018.11.07-18:23:12/cmake/modules/FindLibical.cmake<br>
>> > > > > > >                 [1]<br>
>> > > > > > ><br>
>> > >  <br>
>> /usr/local/src/kmm/kmymoney-5.0-2018.11.07-18:23:12/CMakeLists.txt<br>
>> > > > > > > CMake Error at cmake/modules/FindLibical.cmake:75  <br>
>> (message):<br>
>> > > > > > >   Unable to compile or run the libical version detection<br>
>> > > program.<br>
>> > > > > > > Call Stack (most recent call first):<br>
>> > > > > > >   CMakeLists.txt:242 (find_package)<br>
>> > > > > > ><br>
>> > > > > > ><br>
>> > > > > > >    Called from: [2]<br>
>> > > > > > ><br>
>> > > > > ><br>
>> > > > ><br>
>> > > ><br>
>> > ><br>
>> >  <br>
>> /usr/local/src/kmm/kmymoney-5.0-2018.11.07-18:23:12/cmake/modules/FindLibical.cmake<br>
>> > > > > > >                 [1]<br>
>> > > > > > ><br>
>> > >  <br>
>> /usr/local/src/kmm/kmymoney-5.0-2018.11.07-18:23:12/CMakeLists.txt<br>
>> > > > > > > -- Configuring incomplete, errors occurred!<br>
>> > > > > > > See also<br>
>> > > > > > ><br>
>> > > > > ><br>
>> > > > ><br>
>> > > ><br>
>> > ><br>
>> >  <br>
>> "/usr/local/src/kmm/kmymoney-5.0-2018.11.07-18:23:12/build/CMakeFiles/CMakeOutput.log".<br>
>> > > > > > > See also<br>
>> > > > > > ><br>
>> > > > > ><br>
>> > > > ><br>
>> > > ><br>
>> > ><br>
>> >  <br>
>> "/usr/local/src/kmm/kmymoney-5.0-2018.11.07-18:23:12/build/CMakeFiles/CMakeError.log".<br>
>> > > > > > > make: *** No targets specified and no makefile found.   <br>
>> Stop.<br>
>> > > > > > ><br>
>> > > > > > >  <br>
>> =============================================================<br>
>> > > > > > ><br>
>> > > > > > >                 [1]<br>
>> > > > > > ><br>
>> > >  <br>
>> /usr/local/src/kmm/kmymoney-5.0-2018.11.07-18:23:12/CMakeLists.txt<br>
>> > > > > > > -- Found PythonLibs: //lib64/<a href="http://libpython2.7.so" rel="noreferrer" target="_blank">libpython2.7.so</a> (found  <br>
>> suitable<br>
>> > > > > version<br>
>> > > > > > > "2.7.15", minimum required is "2.7.15")<br>
>> > > > > > >    Called from: [4]<br>
>> > > > > /usr/share/cmake/Modules/FindPackageMessage.cmake<br>
>> > > > > > >                 [3]<br>
>> > > > > > >  <br>
>> /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake<br>
>> > > > > > >                 [2]<br>
>> > > /usr/share/cmake/Modules/FindPythonLibs.cmake<br>
>> > > > > > >                 [1]<br>
>> > > > > > ><br>
>> > >  <br>
>> /usr/local/src/kmm/kmymoney-5.0-2018.11.07-18:23:12/CMakeLists.txt<br>
>> > > > > > > -- Could NOT find PY_weboob (missing: PY_WEBOOB)<br>
>> > > > > > >    Called from: [4]<br>
>> > > > > > >  <br>
>> /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake<br>
>> > > > > > >                 [3]<br>
>> > > > > > >  <br>
>> /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake<br>
>> > > > > > >                 [2]<br>
>> > > > > > ><br>
>> > > > > ><br>
>> > > > ><br>
>> > > ><br>
>> > ><br>
>> >  <br>
>> /usr/local/src/kmm/kmymoney-5.0-2018.11.07-18:23:12/cmake/modules/FindPythonModule.cmake<br>
>> > > > > > >                 [1]<br>
>> > > > > > ><br>
>> > >  <br>
>> /usr/local/src/kmm/kmymoney-5.0-2018.11.07-18:23:12/CMakeLists.txt<br>
>> > > > > > > -- Configuring incomplete, errors occurred!<br>
>> > > > > > ><br>
>> > > > > > ><br>
>> > > > > > > ----<br>
>> > > > > > > Brendan Coupe<br>
>> > > > > > > On Wed, Nov 7, 2018 at 5:42 PM Jack<br>
>> > > > > <<a href="mailto:ostroffjh@users.sourceforge.net" target="_blank">ostroffjh@users.sourceforge.net</a>><br>
>> > > > > > > wrote:<br>
>> > > > > > > ><br>
>> > > > > > > > On 2018.11.07 19:22, Brendan Coupe wrote:<br>
>> > > > > > > > > weboob errors seem to be unfixable in Fedora. I  <br>
>> think they<br>
>> > > > > have<br>
>> > > > > > > been<br>
>> > > > > > > > > around for a while, I found them in previous  <br>
>> requests for<br>
>> > > > > help. I<br>
>> > > > > > > > > don' think they have anything to do with the compile<br>
>> > > failing.<br>
>> > > > > not<br>
>> > > > > > > > > sure if they cause any of the weird behavior I was<br>
>> > > seeing. I<br>
>> > > > > will<br>
>> > > > > > > try<br>
>> > > > > > > > > to resurrect an old F28 system. I'm hoping the repos  <br>
>> have<br>
>> > > > > 5.0.2<br>
>> > > > > > > soon<br>
>> > > > > > > > > since I'm currently running 5.0.1 and dealing with  <br>
>> old<br>
>> > > > > problems<br>
>> > > > > > > that<br>
>> > > > > > > > > have been fixed.<br>
>> > > > > > > > I agree weboob is not relevant here.<br>
>> > > > > > > > ><br>
>> > > > > > > > > Is this the detection program you are talking about:<br>
>> > > > > > > > > cmake/modules/FindLibical.cmake<br>
>> > > > > > > > No, the .cmake program tells cmake where to look for  <br>
>> stuff,<br>
>> > > and<br>
>> > > > > how<br>
>> > > > > > > to<br>
>> > > > > > > > set various variables used later in the cmake run.  To<br>
>> > > actually<br>
>> > > > > > > check,<br>
>> > > > > > > > cmake creates a .c program (using hints and info from  <br>
>> the<br>
>> > > .cmake<br>
>> > > > > > > file,<br>
>> > > > > > > > and then tries to compile and link it.  (Some checks  <br>
>> might<br>
>> > > be<br>
>> > > > > done<br>
>> > > > > > > with<br>
>> > > > > > > > pkg_config)  Normally that fails if libical isn't  <br>
>> found, or<br>
>> > > > > isn't a<br>
>> > > > > > > > high enough version, for example.  Your error says "  <br>
>> Unable<br>
>> > > to<br>
>> > > > > > > compile<br>
>> > > > > > > > or run the libical version detection program." which  <br>
>> seems<br>
>> > > like<br>
>> > > > > a<br>
>> > > > > > > > different sort of problem.  I would look through the  <br>
>> cmake<br>
>> > > > > --help<br>
>> > > > > > > > output to see what parameters might provide additional<br>
>> > > details<br>
>> > > > > about<br>
>> > > > > > > > what is actually failing.<br>
>> > > > > > > > ><br>
>> > > > > > > > > Line 75 is the source of the message.<br>
>> > > > > > > > > gcc.x86_64                                   <br>
>> 8.2.1-4.fc29<br>
>> > > > > > > > >          @updates<br>
>> > > > > > > > > gcc-c++.x86_64                               <br>
>> 8.2.1-4.fc29<br>
>> > > > > > > > >          @updates<br>
>> > > > > > > > > gcc-gdb-plugin.x86_64                        <br>
>> 8.2.1-4.fc29<br>
>> > > > > > > > >          @updates<br>
>> > > > > > > > > libgcc.x86_64                                <br>
>> 8.2.1-4.fc29<br>
>> > > > > > > > >          @updates<br>
>> > > > > > > > This, however, might be the issue.  I'll have to try<br>
>> > > installing<br>
>> > > > > gcc<br>
>> > > > > > > 8<br>
>> > > > > > > > and see how it works for me.  As a temporary fix, you  <br>
>> might<br>
>> > > try<br>
>> > > > > > > using<br>
>> > > > > > > > gcc 7.<br>
>> > > > > > > ><br>
>> > > > > > > > Jack<br>
>> > > > > > > > ><br>
>> > > > > > > > > ----<br>
>> > > > > > > > > Brendan Coupe<br>
>> > > > > > > > > On Wed, Nov 7, 2018 at 4:47 PM Jack<br>
>> > > > > > > <<a href="mailto:ostroffjh@users.sourceforge.net" target="_blank">ostroffjh@users.sourceforge.net</a>><br>
>> > > > > > > > > wrote:<br>
>> > > > > > > > > ><br>
>> > > > > > > > > > Hello Brendan,<br>
>> > > > > > > > > ><br>
>> > > > > > > > > > On 2018.11.07 18:17, Brendan Coupe wrote:<br>
>> > > > > > > > > > > I have been compiling from source for 10+ years.  <br>
>> I had<br>
>> > > > > been<br>
>> > > > > > > able<br>
>> > > > > > > > > to<br>
>> > > > > > > > > > > compile both the master branch and the 5.0  <br>
>> branch on<br>
>> > > my<br>
>> > > > > > > Fedora 28<br>
>> > > > > > > > > > > system until a month or so ago. I was having some<br>
>> > > weird<br>
>> > > > > > > behavior<br>
>> > > > > > > > > in<br>
>> > > > > > > > > > > KMM5 that was not affecting a clean Fedora 28  <br>
>> test VM<br>
>> > > > > running<br>
>> > > > > > > KMM<br>
>> > > > > > > > > > > from the repos so I decided to build a new clean<br>
>> > > Fedora 29<br>
>> > > > > > > system.<br>
>> > > > > > > > > > It may be worth checking the release notes for  <br>
>> Fedora<br>
>> > > 29 to<br>
>> > > > > see<br>
>> > > > > > > what<br>
>> > > > > > > > > > changed, and if anything looks possibly relevant.<br>
>> > > > > > > > > ><br>
>> > > > > > > > > > > I also upgraded the old system from Fedora 28 to  <br>
>> 29.<br>
>> > > Both<br>
>> > > > > > > systems<br>
>> > > > > > > > > > > fail at the same point while compiling from the  <br>
>> master<br>
>> > > > > and 5.0<br>
>> > > > > > > > > > > branches:<br>
>> > > > > > > > > > It certainly sounds like some difference between  <br>
>> 28 and<br>
>> > > 29<br>
>> > > > > is<br>
>> > > > > > > behind<br>
>> > > > > > > > > > the failure.<br>
>> > > > > > > > > ><br>
>> > > > > > > > > > > -- Found LibOfx:<br>
>> > > > > > > > > > > -- Performing Test LIBOFX_HAVE_CLIENTUID<br>
>> > > > > > > > > > > -- Performing Test LIBOFX_HAVE_CLIENTUID -  <br>
>> Success<br>
>> > > > > > > > > > > -- Found PythonInterp: /usr/bin/python2 (found<br>
>> > > suitable<br>
>> > > > > > > version<br>
>> > > > > > > > > > > "2.7.15", minimum required is "2.6")<br>
>> > > > > > > > > > > -- Found PythonLibs: /usr/lib64/<a href="http://libpython2.7.so" rel="noreferrer" target="_blank">libpython2.7.so</a>  <br>
>> (found<br>
>> > > > > > > suitable<br>
>> > > > > > > > > > > version "2.7.15", minimum required is "2.7.15")<br>
>> > > > > > > > > > > -- Could NOT find PY_weboob (missing: PY_WEBOOB)<br>
>> > > > > > > > > > I'm assuming this is not an issue for you.<br>
>> > > > > > > > > > > CMake Error at cmake/modules/FindLibical.cmake:75<br>
>> > > > > (message):<br>
>> > > > > > > > > > >   Unable to compile or run the libical version<br>
>> > > detection<br>
>> > > > > > > program.<br>
>> > > > > > > > > > This does seem odd.  It appears not even getting  <br>
>> to the<br>
>> > > > > point of<br>
>> > > > > > > > > > actually checking for an installed libical.<br>
>> > > > > > > > > > > Call Stack (most recent call first):<br>
>> > > > > > > > > > >   CMakeLists.txt:242 (find_package)<br>
>> > > > > > > > > > At the point of failure, check in the build  <br>
>> directory.<br>
>> > > > > Often<br>
>> > > > > > > you<br>
>> > > > > > > > > can<br>
>> > > > > > > > > > find the libical version detection program (I've<br>
>> > > forgotten<br>
>> > > > > > > whether<br>
>> > > > > > > > > it<br>
>> > > > > > > > > > leaves the .c program around, and see if  <br>
>> configure.log<br>
>> > > (or<br>
>> > > > > > > something<br>
>> > > > > > > > > > like it) might have a more detailed reason for the<br>
>> > > failure<br>
>> > > > > to<br>
>> > > > > > > > > compile<br>
>> > > > > > > > > > that .c program.<br>
>> > > > > > > > > ><br>
>> > > > > > > > > > Not sure if it might be relevant, but what version  <br>
>> of<br>
>> > > gcc<br>
>> > > > > are<br>
>> > > > > > > you<br>
>> > > > > > > > > > using, both in F28 and in F29?<br>
>> > > > > > > > > > ><br>
>> > > > > > > > > > > -- Configuring incomplete, errors occurred!<br>
>> > > > > > > > > > > ========================================<br>
>> > > > > > > > > > ><br>
>> > > > > > > > > > > libical appears to be installed:<br>
>> > > > > > > > > > ><br>
>> > > > > > > > > > ><br>
>> > > > > > > > > > > dnf list installed | grep libical<br>
>> > > > > > > > > > > libical.x86_64<br>
>> > > > > > > > > 3.0.3-7.fc29<br>
>> > > > > > > > > > >                                  @fedora<br>
>> > > > > > > > > > > libical-devel.x86_64<br>
>> > > > > > > > > 3.0.3-7.fc29<br>
>> > > > > > > > > > >                                  @fedora<br>
>> > > > > > > > > > ><br>
>> > > > > > > > > > > Any ideas?<br>
>> > > > > > > > > > ><br>
>> > > > > > > > > > > Thanks,<br>
>> > > > > > > > > > ><br>
>> > > > > > > > > > > ----<br>
>> > > > > > > > > > > Brendan Coupe<br>
>> > > > > > > > > > Jack<br>
>> > ><br>
>> ><br>
>> ><br>
>> <br>
> <br>
</blockquote></div>