<div dir="ltr"><div><div><div><font face="monospace, monospace">autogen-libopts.x86_64                5.18.12-2.fc26            @@commandline   </font></div><div><font face="monospace, monospace">automake.noarch                       1.15-9.fc26               @@commandline   </font></div><div><font face="monospace, monospace">cmake.x86_64                          3.9.0-8.fc26              @updates        </font></div><div><font face="monospace, monospace">cmake-data.noarch                     3.9.0-8.fc26              @updates        </font></div><div><font face="monospace, monospace">cmake-fedora.noarch                   2.9.1-1.fc26              @updates        </font></div><div><font face="monospace, monospace">cmake-filesystem.x86_64               3.9.0-8.fc26              @updates        </font></div><div><font face="monospace, monospace">make.x86_64                           1:4.2.1-2.fc26            @@commandline</font></div></div></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><font face="tahoma, sans-serif" size="2" color="#073763"><b><br></b></font></div><div dir="ltr"><font face="tahoma, sans-serif" size="2" color="#073763"><b>----<br>Brendan Coupe</b></font><br></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Wed, Aug 9, 2017 at 3:33 PM, Jack <span dir="ltr"><<a href="mailto:ostroffjh@users.sourceforge.net" target="_blank">ostroffjh@users.sourceforge.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">By in or out of tree - it is whether the build directory is below the top source folder (within the source tree) or parallel to it (outside the source tree).  I've never been certain whether it theoretically matters, but it does sometimes make a difference, often due to how make handles the relative paths in the various Makefiles and related cmake files.  I don't know if it will matter, but it might be worth trying.  Note your example doesn't show where you create the build dir, but it can be under $BP but should not under $KMMDIR.<br>
<br>
However - you say you have two examples of failed build where kmymoneysettings.h IS present where we expect it.  So the issue is not whether that file gets built, it's why cmake isn't finding it when it needs it use it.  Looking carefully at the make output you provided, I see "Considering target file '//kmymoneysettings.h'."  I'm concerned about the leading double slash.  I don't know make well enough to say if that is a hint about the problem, but it does smell like it to me.<br>
<br>
What versions of cmake, make, and autogen do you have?  I've got make 4.2.1, cmake  3.7.2, autogen 5.18.4, and automake 1.11.6, 1.13.4 and 1.15.<br>
<br>
Jack<span class=""><br>
<br>
On <a href="tel:2017.08.09%2016" value="+12017080916" target="_blank">2017.08.09 16</a>:53, Brendan Coupe wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
I have several successful build folders left over from before the upgrade<br>
to Fedora 26. They all contain kmymoneysettings.h in {source path)/<br>
build/kmymoney/kmymoneysetting<wbr>s.h<br>
<br>
The 2 recent failed build folders have the same file in the same folder and<br>
they are an exact match.<br>
<br>
I download a fresh copy of the source - 4.8 branch - each time I compile. I<br>
know that's not the most efficient way but I had problems many years ago so<br>
I modified my build script to get a clean copy each time.<br>
<br>
I'm not sure what you mean by in tree or out of tree. My build script<br>
creates a new date and time stamped folder, downloads the source into it,<br>
creates a new folder in the source folder called build and then I run cmake<br>
and make in that folder.<br>
<br>
Here are the relevant lines from my script:<br>
git clone git://<a href="http://anongit.kde.org/kmymoney" rel="noreferrer" target="_blank">anongit.kde.org/kmymoney</a> --branch 4.8  $BP/$KMMDIR<br>
cmake $BP/$KMMDIR -DCMAKE_INSTALL_PREFIX=/usr/<br>
make -j 8<br>
<br>
This all worked fine until I upgrade to Fedora 26 so it seems like it's not<br>
s KMM issue but something has changed in Fedora 26. It's a problem on both<br>
my desktop and laptop. I have one other system that I have not upgraded<br>
that I may be be able to test it on but we just moved and I have not set<br>
that system up yet so I'm not sure when I will get to it.<br>
<br>
<br>
<br>
<br></span>
*----Brendan Coupe*<div><div class="h5"><br>
<br>
On Tue, Aug 8, 2017 at 10:51 AM, Jack <<a href="mailto:ostroffjh@users.sourceforge.net" target="_blank">ostroffjh@users.sourceforge.n<wbr>et</a>><br>
wrote:<br>
<br>
> On <a href="tel:2017.08.07%2019" value="+12017080719" target="_blank">2017.08.07 19</a>:31, Brendan Coupe wrote:<br>
><br>
>> I already tried the libalkimia trick and it did not work this time.<br>
>><br>
> That would only work if it was an alkimia file which was missing, and it<br>
> was missing because your alkimia install was broken.<br>
><br>
>><br>
>> I was running with -j 8. I tried -j 1 and it took a lot longer to fail. I<br>
>> added -d to -j 1 and it also failed. I've copied the last part of the<br>
>> output below (I switched GMail to plain text mode, I hope it works).<br>
>><br>
> Mail formatting is good - thanks.<br>
><br>
>><br>
>> ==============================<wbr>========<br>
>> Updating goal targets....<br>
>> Considering target file<br>
>> 'kmymoney/dialogs/settings/CMa<wbr>keFiles/settings_autogen.dir/<wbr>build'.<br>
>>  File 'kmymoney/dialogs/settings/CMa<wbr>keFiles/settings_autogen.dir/<wbr>build'<br>
>> does not exist.<br>
>><br>
> [snip....]<br>
><br>
>>       Must remake target '//kmymoneysettings.h'.<br>
>><br>
> I probably snipped too many lines, but the problem is it can't find<br>
> kmymoneysettings.h.  That file is not in the source, but gets created in<br>
> $build_dir/kmymoney.  So we need to figure out why it isn't being made.<br>
><br>
> First - what sources are you using?  If you are pulling from git head of<br>
> the 4.8 branch, confirm that "git status" doesn't show anything amiss.<br>
><br>
> Second - are you building in tree, or out of tree.  The latter is<br>
> recommended as safer.<br>
><br>
> If that's not enough, we may have to track down where in the build process<br>
> that file SHOULD be created, and why it's not happening.<br>
><br>
> Jack<br>
><br>
><br>
><br>
>> On Mon, Aug 7, 2017 at 10:57 AM, Jack <<a href="mailto:ostroffjh@users.sourceforge.net" target="_blank">ostroffjh@users.sourceforge.n<wbr>et</a>><br>
>> wrote:<br>
>> > Hello Brendan,<br>
>> ><br>
>> > On <a href="tel:2017.08.07%2012" value="+12017080712" target="_blank">2017.08.07 12</a>:28, Brendan Coupe wrote:<br>
>> >><br>
>> >> I have been compiling KMM from source for many years. I have been using<br>
>> >> the 4.8 branch recently.<br>
>> >><br>
>> >> I upgraded from Fedora 25 to Fedora 26 a couple of weeks ago. Compiling<br>
>> >> fails pretty early in the process. See the last part of the output<br>
>> below. It<br>
>> >> compiled from source without any issues prior to the OS upgrade.<br>
>> >><br>
>> >> Any idea what is going wrong?<br>
>> >><br>
>> >> ==============================<wbr>=========================<br>
>> >> *Generating MOC source EWIEGA46WW/moc_lendborrowwizar<br>
>> dpage.cppGenerating<br>
>> >> MOC source JKU67JSAFJ/moc_KDChartTernaryP<wbr>ointDiagram.cppGenerating MOC<br>
>> >> source EWIEGA46WW/moc_loanamountwizar<wbr>dpage.cppGenerating MOC<br>
>> compilation<br>
>> >> mocs_compilation.cpp[  6%] Built target kmm_kdchart_autogenGenerating<br>
>> MOC<br>
>> >> source EWIEGA46WW/moc_loanattributesw<wbr>izardpage.cppGenerating MOC<br>
>> source<br>
>> >> EWIEGA46WW/moc_namewizardpage.<wbr>cppGenerating MOC source<br>
>> >> EWIEGA46WW/moc_newcalculateloa<wbr>nwizardpage.cppGenerating MOC source<br>
>> >> EWIEGA46WW/moc_newgeneralinfow<wbr>izardpage.cppGenerating MOC source<br>
>> >> EWIEGA46WW/moc_newintrowizardp<wbr>age.cppGenerating MOC source<br>
>> >> EWIEGA46WW/moc_newpaymentswiza<wbr>rdpage.cppGenerating MOC source<br>
>> >> EWIEGA46WW/moc_paymenteditwiza<wbr>rdpage.cppGenerating MOC source<br>
>> >> EWIEGA46WW/moc_paymentfrequenc<wbr>ywizardpage.cppGenerating MOC source<br>
>> >> EWIEGA46WW/moc_paymentwizardpa<wbr>ge.cppGenerating MOC source<br>
>> >> EWIEGA46WW/moc_previouspayment<wbr>swizardpage.cppGenerating MOC source<br>
>> >> EWIEGA46WW/moc_recordpaymentwi<wbr>zardpage.cppGenerating MOC source<br>
>> >> EWIEGA46WW/moc_schedulewizardp<wbr>age.cppGenerating MOC source<br>
>> >> EWIEGA46WW/moc_summaryeditwiza<wbr>rdpage.cppGenerating MOC source<br>
>> >> EWIEGA46WW/moc_summarywizardpa<wbr>ge.cppGenerating MOC source<br>
>> >> EWIEGA46WW/moc_variableinteres<wbr>tdatewizardpage.cppGenerating MOC<br>
>> >> compilation<br>
>> >> mocs_compilation.cpp[  6%] Built target newloanwizard_autogenmake: ***<br>
>> >> [Makefile:163: all] Error 2*<br>
>> >> **============================<wbr>===========================<br>
>> ><br>
>> ><br>
>> > First please consider sending plain text and not HTML to the list - you<br>
>> can<br>
>> > see it messes up wrapping.<br>
>> ><br>
>> > This seems similar to a problem you had last October.   Have you tried<br>
>> "make<br>
>> > -d" (or some slightly less verbose variant) to get debugging info?<br>
>> What -j<br>
>> > value are you using?  I believe at that time, make (or gcc?) couldn't<br>
>> find<br>
>> > some header file, which you fixed by removing and reinstalling<br>
>> libalkimia.<br>
>> ><br>
>> > Jack</div></div></blockquote>
</blockquote></div><br></div>