bugGNU Octave - Bugs: bug #51450, [octave-forge] database 2.4.2...

 
 

bug #51450: [octave-forge] database 2.4.2 fails to build in dev octave 4.3.0+

Submitted by:  John Donoghue <lostbard>
Submitted on:  Wed 12 Jul 2017 12:19:05 PM UTC  
 
Category: Octave Forge PackageSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Build Failure
Status: FixedAssigned to: None
Originator Name: JohnDOpen/Closed: Closed
Release: devOperating System: Any

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Thu 20 Jul 2017 12:12:09 PM UTC, comment #12:

yep - package now builds under windows octave 4.2.1 and 4.3.0+

John Donoghue <lostbard>
Project Member
Thu 20 Jul 2017 09:41:58 AM UTC, comment #11:

Currently no effort is made to make building the extra docs work under Windows or while cross-building. The extra docs should be pre-built natively. This is also noted in a comment at the top of src/Makefile.in.

I checked in a patch which fixes pre-building the extra docs with the release: target of the toplevel Makefile. Is that enough for your needs?

Olaf Till <i7tiol>
Project Member
Wed 19 Jul 2017 05:48:02 PM UTC, comment #10:

Which reminds me that in mxe-octave, in order to get it to cross compile, I assigned in the Makefile:

BUILD_CXX ?= gcc

and for the CXX in the doc rule to BUILD_CXX

John Donoghue <lostbard>
Project Member
Wed 19 Jul 2017 05:43:39 PM UTC, comment #9:

I guess should be a new bug report, but attempting to compile under windows (using latest from the repo)

Trying to run the pq_update_types.bin file afterwards gives same
'Bad file number' error

John Donoghue <lostbard>
Project Member
Tue 18 Jul 2017 07:06:36 PM UTC, comment #8:

A fix is pushed, including a general frame to deal with simple symbol changes. I suggest to use this frame for similar cases, it'll be published at the OF website.

Deprecated symbols don't seem to be available long enough for my previous strategy to work.

As for filing bugs for build failures with dev, I can't suggest a general rule. In the packages which I maintain I think I would fix these even without reports, but in some cases not before dev is about to become the next major release. But your build fixes against dev for many packages are doubtless really useful.

On the other hand, maybe a development strategy for the Windows build could be devised in which you have more time to wait for (or produce...) build fixes of packages against dev ...? It's only because package development normally doesn't immediately parallel each change in Octave dev, except on Windows.

Olaf Till <i7tiol>
Project Member
Wed 12 Jul 2017 02:39:25 PM UTC, comment #7:

I guess the question is really, should we post build failures of packages against dev as bugs?

In the mean time, I have a fix for building/testing

John Donoghue <lostbard>
Project Member
Wed 12 Jul 2017 02:37:00 PM UTC, comment #6:

But it was with Octaves development version, which AFAIK is not near a release. So I'm not sure that I should take this failure as the trigger to switch from deprecated to modern.

Olaf Till <i7tiol>
Project Member
Wed 12 Jul 2017 02:29:37 PM UTC, comment #5:

In this case, it was more than just a depreciated symbol - it wont compile. It does print out a number of other messages about depreciated functions as well - I was ignoring them

John Donoghue <lostbard>
Project Member
Wed 12 Jul 2017 12:54:29 PM UTC, comment #4:

I didn't see your patch, it crossed with my last post. However, my current strategy with deprecated symbols in Octave is to use the deprecated ones as long as they are supported and then to unconditionally switch to the replacements. This spares testing for each single deprecated symbol and should (?) still provide compatibility with a certain range of Octave versions.

Olaf Till <i7tiol>
Project Member
Wed 12 Jul 2017 12:44:17 PM UTC, comment #3:

Probally not - just for testing mxe-octave with dev octave.

John Donoghue <lostbard>
Project Member
Wed 12 Jul 2017 12:28:40 PM UTC, comment #2:

I tend to adapt to Octaves API changes in the development branch only in greater chunks, preferably after some re-structuring of Octave is finished. Do you need this fixed already now for some reason?

Olaf Till <i7tiol>
Project Member
Wed 12 Jul 2017 12:25:30 PM UTC, comment #1:

Patch checking for mach_info

(file #41190)

John Donoghue <lostbard>
Project Member
Wed 12 Jul 2017 12:19:05 PM UTC, original submission:

With recent changes in name spaces in octave:

John Donoghue <lostbard>
Project Member

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #41190:  namespace.patch added by lostbard (2KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by mtmiller (Updated the item)
  • -unavailable- added by i7tiol (Posted a comment)
  • -unavailable- added by lostbard (Adding package maintainer)
  • -unavailable- added by lostbard (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 20 Jul 2017 05:32:59 PM UTCmtmillerStatusNone=>Fixed
      Open/ClosedOpen=>Closed
    Wed 12 Jul 2017 12:25:30 PM UTClostbardAttached File-=>Added namespace.patch, #41190
    Wed 12 Jul 2017 12:21:18 PM UTClostbardCarbon-Copy-=>Added -unavailable-

    Back to the top


    Powered by Savane 3.1-cleanup1