bugGNU Octave - Bugs: bug #47317, "make tags" fails

 
 

bug #47317: "make tags" fails

Submitter:  Rik <rik5>
Submitted:  Tue 01 Mar 2016 09:00:38 PM UTC
   
 
Category:  Configuration and Build System Severity:  2 - Minor
Priority:  5 - Normal Item Group:  Regression
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Wed 02 Mar 2016 04:38:06 AM UTC, comment #5: 

It might be worth experimenting with eliminating the convenience libraries just to see what would happen but I'm not sure that there will be much difference.

The convenience libraries are just old-style archives created using ar, so building them should be fairly fast as no linking actually happens at that step.

There should be no dependencies between any of the convenience libraries that are combined to make any one of the 3 main libraries.  I think that means that it should already be possible to compile all of the object files at once if you had enough memory and CPU capacity to run about 1400 simultaneous compile jobs.

John W. Eaton <jwe>
Group administrator
Wed 02 Mar 2016 02:15:19 AM UTC, comment #4: 

I added another changeset that correctly ADDS the m-files to the list of files to calculate tags for.  The old rule was overwriting the file list so that no C/C++/Fortran sources were included in the tags file.

Closing report.

Rik <rik5>
Group administrator
Wed 02 Mar 2016 01:29:53 AM UTC, comment #3: 

Yeah, that's probably an okay temporary solution. I'd like to try eliminating the intermediate libraries in the long run. Now that we build the libraries fully non-recursively we should be able to combine all of the SOURCES lists and just build 4 libraries, libgnu, liboctave, liboctinterp, and liboctgui. This should also increase parallelism, linking is always the big choke point.

Mike Miller <mtmiller>
Group Member
Wed 02 Mar 2016 01:13:51 AM UTC, comment #2: 

I think I see what is going on.  According to the Automake documentation:


For each primary, there is one additional variable named by prepending ‘EXTRA_’ to the primary name. This variable is used to list objects that may or may not be built, depending on what configure decides. This variable is required because Automake must statically know the entire list of objects that may be built in order to generate a Makefile.in that will work in all cases.


Separately, the hack we are using to force liboctave and libgui to be linked using the CXX linker is also in the documentation.



If one of the sublibraries contains non-C source, it is important that the appropriate linker be chosen. One way to achieve this is to pretend that there is such a non-C file among the sources of the library, thus forcing automake to select the appropriate linker. Here is the top-level Makefile of our example updated to force C++ linking.

SUBDIRS = sub1 sub2 …
lib_LTLIBRARIES = libtop.la
libtop_la_SOURCES =
# Dummy C++ source to cause C++ linking.
nodist_EXTRA_libtop_la_SOURCES = dummy.cxx
libtop_la_LIBADD = \
  sub1/libsub1.la \
  sub2/libsub2.la \
  …

‘EXTRA_*_SOURCES’ variables are used to keep track of source files that might be compiled (this is mostly useful when doing conditional compilation using AC_SUBST, see Conditional Libtool Sources), and the nodist_ prefix means the listed sources are not to be distributed (see Program and Library Variables). In effect the file dummy.cxx does not need to exist in the source tree. Of course if you have some real source file to list in libtop_la_SOURCES there is no point in cheating with nodist_EXTRA_libtop_la_SOURCES.


I think the problem is that the EXTRA_ tag is meant to be used for conditional compilation where some of the files might or might not be included in a particular build.  This works fine for our build system because there are no rules to process dummy.cxx and there are no dependencies on dummy.cxx.  The only result is a side effect that the generated linker command is for C++ sources.

However, tags, ctags, and scope are meant to operate on all files declared in _SOURCES.  Just because the file isn't used in this particular build, doesn't mean it doesn't require indexing.

I pushed a cset that makes a real file .dummy_force_cxx_link.cc in liboctave and libgui.  The file is empty and the leading '.' should make it invisible most of the time.  I opted to distribute it in the tarball so that someone could use the tags or cscope target after downloading.  If we feel that these makefile targets are only for developers then we could add nodist_ to the Automake rule.


Rik <rik5>
Group administrator
Tue 01 Mar 2016 10:42:10 PM UTC, comment #1: 

Confirmed, also "make cscope". Touching the two files libgui/dummy.cc and liboctave/dummy.cc is enough to allow these two targets to succeed.

The dummy.cc files are needed to force C++ linkage. The "EXTRA" tag is supposed to tell the build that the file is not actually needed to compile, but apparently still needed for tags/ctags/cscope.

Also now noticing that there is a custom "ctags" target in scripts/module.mk that probably shouldn't be there, maybe inadvertently left in when the build was converted to non-recursive.

Mike Miller <mtmiller>
Group Member
Tue 01 Mar 2016 09:00:38 PM UTC, original submission:  

The tags target is one of the standard targets that should be available for every Makefile (https://www.gnu.org/software/make/manual/html_node/Standard-Targets).  When I try 'make tags' I get


make[1]: *** No rule to make target 'libgui/dummy.cc', needed by 'tags-am'.  Stop.
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory '/home/rik/wip/Projects_Mine/octave-dev'
Makefile:25582: recipe for target 'tags-recursive' failed


I can use 'ctags -R' from the top-level directory, but that will also end up including files in libgnu and gnulib-hg that I don't particularly want to index.

Rik <rik5>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by rik5 (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-03-02 rik5 StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2016-03-02 rik5 Carbon-Copy- Added jwe
    2016-03-01 mtmiller StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code