bugGNU Octave - Bugs: bug #46260, build with --disable-docs doesn't...

 
 

bug #46260: build with --disable-docs doesn't build oct-files until "make install"

Submitter:  Mike Miller <mtmiller>
Submitted:  Wed 21 Oct 2015 01:01:59 AM 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:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 01 Mar 2016 04:13:37 PM UTC, comment #10: 

Fixed!  Closing report.

Rik <rik5>
Group administrator
Tue 01 Mar 2016 08:27:04 AM UTC, comment #9: 
John W. Eaton <jwe>
Group administrator
Mon 29 Feb 2016 11:05:27 PM UTC, comment #8: 

Apparently creating the .oct files is not enough.

I did


make maintainer-clean
sh bootstrap
./configure --disable-docs
make |& tee mymake.log


octave is successfully built, and the .oct files are generated, but when running run-octave the FLTK toolkit is still not available.

I then ran


make V=1 check


to see what else happens.  I have excerpted the section of the log dealing with _init_fltk_.cc.


rm -f libinterp/dldfcn/__init_fltk__.df-t libinterp/dldfcn/__init_fltk__.df-t1 libinterp/dldfcn/__init_fltk__.df && \
g++ -std=gnu++11 -E -DHAVE_CONFIG_H -I.  \
  -Iliboctave -I./liboctave -I./liboctave/cruft/misc -I./liboctave/array -Iliboctave/numeric -I./liboctave/numeric -Iliboctave/operators -I./liboctave/operators -I./liboctave/system -I./liboctave/util -I./libinterp/octave-value -Ilibinterp -I./libinterp -I./libinterp/operators -Ilibinterp/parse-tree -I./libinterp/parse-tree -Ilibinterp/corefcn -I./libinterp/corefcn -Ilibgnu -I./libgnu   -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12  -I/usr/include/freetype2 -DCP936  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -I/usr/include/freetype2  -I/usr/include/freetype2  \
  -pthread -fopenmp -Wall -W -Wshadow -Wold-style-cast -Wformat -Wpointer-arith -Wwrite-strings -Wcast-align -Wcast-qual -g -O0 -pipe \
  -DMAKE_BUILTINS libinterp/dldfcn/__init_fltk__.cc > libinterp/dldfcn/__init_fltk__.df-t1 && \
/bin/bash ./libinterp/mkdefs ./libinterp libinterp/dldfcn/__init_fltk__.cc < libinterp/dldfcn/__init_fltk__.df-t1 > libinterp/dldfcn/__init_fltk__.df-t && \
rm -f libinterp/dldfcn/__init_fltk__.df-t1 && \
mv libinterp/dldfcn/__init_fltk__.df-t libinterp/dldfcn/__init_fltk__.df


It seems that there needs to be a dependency on the .df files as well.  However, just re-building _init_fltk_.df was not enough.  I also had to 'make libinterp/dldfcn/PKG_ADD'.  Given that PKG_ADD depends on all the .df files that is probably a better dependency to try and add to the build system.

Alternatively, why don't we just add OCTAVE_INTERPRETER_TARGETS to all-local in Makefile.am at the top level?  The variable is supposed to expand out into whatever is necessary to use run-octave and is a dependency of the documentation targets that might use run-octave to generate images.  Shouldn't 'make all' produce everything necessary for the interpreter as well?



Rik <rik5>
Group administrator
Mon 29 Feb 2016 09:42:31 PM UTC, comment #7: 

OK, I checked in the following change:

http://hg.savannah.gnu.org/hgweb/octave/rev/f20af4d085e9

John W. Eaton <jwe>
Group administrator
Mon 29 Feb 2016 09:25:13 PM UTC, comment #6: 

@jwe: That was my thinking.  You could add OCT_FILES directly to all-local in Makefile.am at the top level.  Or if you want the dependency closer to the source you could rely on the ALL_LOCAL_TARGETS variable at the top level, and add a local target in libinterp/module.mk or libinterp/dldfcn/module.mk (which is auto-generated).

Rik <rik5>
Group administrator
Mon 29 Feb 2016 08:33:51 PM UTC, comment #5: 

Or, a slightly different question.  Is there any reason to NOT have $(OCT_FILES) as a dependency of all-local instead of just as a dependency for check and doc targets?

John W. Eaton <jwe>
Group administrator
Mon 29 Feb 2016 04:45:40 AM UTC, comment #4: 

Should run-octave depend on the .oct file targets?  I guess it would be nice if the version of Octave in the build tree is fully functional even if the documentation is not built.  If not run-octave, then maybe some other target?  Maybe the main octave programs or libinterp?

John W. Eaton <jwe>
Group administrator
Mon 29 Feb 2016 04:33:11 AM UTC, comment #3: 

There is a definition in the build system for all the dldfcn .oct files: OCT_FILES.  The trouble is that only OCTAVE_INTERPRETER_TARGETS includes OCT_FILES and OCTAVE_INTERPRETER_TARGETS is only a dependency for 'make check' and 'make doc' because they need run-octave to work.

Rik <rik5>
Group administrator
Sun 28 Feb 2016 07:13:29 PM UTC, comment #2: 

I'll take a look at this one.

John W. Eaton <jwe>
Group administrator
Sun 28 Feb 2016 07:05:23 PM UTC, comment #1: 

Symptoms of oct-file symlinks not there include gnuplot and fltk toolkits are not available, image functions don't work because _magick* functions are not callable, etc.

Mike Miller <mtmiller>
Group Member
Wed 21 Oct 2015 01:01:59 AM UTC, original submission:  

Building Octave with --disable-docs doesn't actually create the oct-files under libinterp/dldfcn. The object files are linked (e.g. libinterp/dldfcn/.libs/amd.so) but the .oct file is not built. When "make install" is run, the oct-files are created in the install target path, but still not in the build tree.

I'm guessing this is because the oct-files are a dependency for running Octave to build the documentation, but not a dependency of the "all" target.

Running "make check" does generate the oct-files.

Mike Miller <mtmiller>
Group Member

 

(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

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Updated the item)
  • -email is unavailable- added by rik5
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by mtmiller (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 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-03-01 rik5 StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2016-02-29 rik5 Carbon-Copy- Added jwe
    2016-02-29 rik5 Assigned tojwe None
    2016-02-28 jwe Assigned toNone jwe
    2016-02-28 mtmiller StatusNone Confirmed
    2016-02-28 mtmiller Dependencies- bugs #46031 is dependent

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code