https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-576 Lustre <p>The dependencies listed for the libcfsutil.a target are incorrect. The sources for that library are listed in libcfs/libcfs/autoMakefile.am as:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>libcfsutil_a_SOURCES = nidstrings.c util/parser.c util/parser.h util/platform.h \ util/l_ioctl.c util/util.c </pre> </div></div> <p>Expanding out the above relative pathnames for the referenced <span class="error">&#91;parser|platform&#93;</span>.h files gives the following files:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>libcfs/libcfs/util/parser.h libcfs/libcfs/util/platform.h </pre> </div></div> <p>The problem is these files do not exist. My assumption is, the dependencies it is intending to use are the following files:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>libcfs/include/libcfs/util/parser.h libcfs/include/libcfs/util/platform.h </pre> </div></div> <p>Even worse, the <span class="error">&#91;parser|platform&#93;</span>.c files do not reference <span class="error">&#91;parser|platform&#93;</span>.h directly. These files are included through the directive:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>#include &lt;libcfs/libcfsutil.h&gt; </pre> </div></div> <p>But a dependency on libcfsutil.h is not in the *_SOURCES variable.</p> <p>I think the right thing to do in this situation would be to fix these path issues using an "absolute" path to the needed files, using a reference to the top of the source tree. For example:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>libcfsutil_a_SOURCES = $(top_srcdir)/libcfs/libcfs/util/nidstrings.c \ $(top_srcdir)/libcfs/libcfs/util/parser.c \ $(top_srcdir)/libcfs/libcfs/util/l_ioctl.c \ $(top_srcdir)/libcfs/libcfs/util/util.c \ $(top_srcdir)/libcfs/include/libcfs/util/parser.h \ $(top_srcdir)/libcfs/include/libcfs/util/platform.h \ $(top_srcdir)/libcfs/include/libcfs/libcfsutil.h </pre> </div></div> <p>Although, full pathnames are not used throughout the build system for Lustre, thus the inconsistency of using full pathnames here is not ideal.</p> <p>The patch submitted for <a href="https://jira.whamcloud.com/browse/LU-455" title="autogen.sh preparation produces automake chatter" class="issue-link" data-issue-key="LU-455"><del>LU-455</del></a>, <a href="http://review.whamcloud.com/#change,1092" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#change,1092</a>, "fixes" this issue simply by removing the <span class="error">&#91;parser|platform&#93;</span>.h dependencies from the list of *_SOURCES.</p> Lustre 2.0.66 LU-576

Incorrect build dependencies listed for libcfsutil.a

Bug Minor Resolved Low Priority Minh Diep Prakash Surya llnl Mon, 8 Aug 2011 13:25:46 +0000 Wed, 6 Nov 2019 06:04:57 +0000 Wed, 6 Nov 2019 06:04:57 +0000 Lustre 2.0.0 Lustre 2.1.0 0 4 <p>Brian</p> <p>Could you please comment?</p> <p>Prakash</p> <p>Does this mean that we should not land the patch from LU455?</p> <p>Peter</p> <p>Peter,</p> <p>No, I definitely think the LU455 patch should still land.</p> <p>This "fix" I mention in the LU455 patch isn't changing any of the current behaviour. From the looks of it, it has always been broken, it was just wasn't being reported when using the DIST_SOURCES automake variable. So what was "broken" before is still "broken" with the LU455 patch, we just can no longer rely on the build system to hide the error for us.</p> <p>Patches to properly fix this ticket should be made separately. Although, the "right" fix that I mention is probably only possible with a total rehaul of the build system.</p> <p>ok, thanks for clarifying Prakash</p> <p>I don't particularly have an issue with selective use of the full path, however couldn't a relative path also be used?</p> <p>i.e.</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">libcfsutil_a_SOURCES = nidstrings.c util/parser.c ../include/libcfs/util/parser.h ../include/libcfs/util/platform.h \ util/l_ioctl.c util/util.c </pre> </div></div> <p>My issue with using the full paths is that doesn't look to be the way things are done anywhere else in the build system. Even though I think it's the right fix, without going through and making the change everywhere, it still feels like an ugly hack. I'm sure I could look through the tree to answer this, but do you know how this sort of issue is handled in the other subsystems? I imagine having a separate 'include' directory is a common idiom.</p> <p>And I haven't tried using '..' but technically I think it would work just fine. That solution just doesn't sit well with me.. Is there a good argument for '..' over full paths?</p> <p>Isn't the benefit of using relative paths the fact that you can move the top level directories around and things will still work? If '..' is used then you lock yourself into the current directory structure without explicitly spelling out the structure you expect by using the full paths.</p> <p>I know Chris Morrone also wasn't too keen using '..' to find the header files as well, although I'm not sure what his reasoning on that was. Perhaps it would be a good idea to add him to the watch list and see what he says about this matter.</p> <p>chris,</p> <p>Adding you for your comments</p> <p>Thanks</p> <p>Peter</p> <p>Mostly I want to be clear that we think this is likely a common problem in the build system. I don't think there is a point to fixing just these two. If we fix it, we should figure out the correct solution and apply it everywhere that it is needed.</p> <p>I see no hurry to fix this either. I think that making some of the bigger changes like moving ldiskfs and the lustre kernel patches out of the lustre tree would be excellent first steps to cleaning up the build system. Once those are done, it will be easier to start some of the finer cleanup like this.</p> <p>I would not suggest using the full path when the files are in the same directory as the makefile, or in subdirectories below the make file. I would perhaps only use the $(top_builddir) form of the path when we need to walk back up the tree. I am not really particularly opposed to using "..", though.</p> <p>Minh is working on this area nowadays</p> <p>Chris, Prakash</p> <p>Could you let me know what else need to be done for this ticket?</p> <p>Thanks</p> <p>The patch <a href="http://review.whamcloud.com/1092" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/1092</a> was landed in 2011-08-12 for v2_0_66_0-40-g88ae427. Is there anything left to fix, or should this be closed?</p> <p>Chris, Prakash,<br/> Can I mark this as resolved?<br/> Thanks,<br/> ~ jfc.</p> <p><a href="http://review.whamcloud.com/1092" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/1092</a> was for <a href="https://jira.whamcloud.com/browse/LU-455" title="autogen.sh preparation produces automake chatter" class="issue-link" data-issue-key="LU-455"><del>LU-455</del></a>, not this ticket. I can't remember this being fixed off the top of my head. I don't have time to do a more thorough search at the moment. My assumption is that is has not been addressed until proven otherwise.</p> <p>It isn't clear that this is still a problem for anyone.</p> Development End date Fri, 27 Jun 2014 13:25:46 +0000 Rank 1|hzvt2f: Rank (Obsolete) 8639 Severity Start date Mon, 8 Aug 2011 13:25:46 +0000