octave-1.1.tcl

[Schamschula (Marius Schamschula)]

As the maintainer of several octave packages, I've looked at the octave-1.0 PortGroup. For some unknown reason this PortGroup builds the package during the configure stage. This sequence is not intuitive. It also means that the post-patch phase is defined by the PortGroup, and thus is unavailable to the maintainer. For example, this phase is needed for octave-tsa to correctly set the path to libgomp.

I have modified the PortGroup as follows:

post-patch -> configure

pre-configure -> pre-build

build has been enabled with

build.target ""

[larryv (Lawrence Velázquez)]

Is it really necessary to increase the portgroup version?

Replying to mschamschula@…:

It also means that the post-patch phase is defined by the PortGroup, and thus is unavailable to the maintainer. For example, this phase is needed for octave-tsa to correctly set the path to libgomp.

Do you actually need to disable the portgroup’s post-patch script? A port can easily define additional post-patch phases.

[larryv (Lawrence Velázquez)]

It’s not at all clear to me what you’ve changed. Please attach a diff based on the current portgroup.

[michaelld (Michael Dickens)]

I believe the reason I used configure for building is that all of the various *FLAGS are set correctly in it, while they are not guaranteed to be set during the build phase. It was a compromise at the time, knowing that some of the Octave module ports would be challenging to work with -- not impossible, just difficult. Maybe moving things around will work now correctly?

Have you tested whatever changes you made here with the other Octave module ports? If they work as before, then let me do some testing with your changes. But, I'd like some confirmed diligence on your end before I too to much testing on my end.

[Schamschula (Marius Schamschula)]

Replying to larryv@…:

It’s not at all clear to me what you’ve changed. Please attach a diff based on the current portgroup.

diff file attached.

[Schamschula (Marius Schamschula)]

Replying to michaelld@…:

I believe the reason I used configure for building is that all of the various *FLAGS are set correctly in it, while they are not guaranteed to be set during the build phase. It was a compromise at the time, knowing that some of the Octave module ports would be challenging to work with -- not impossible, just difficult. Maybe moving things around will work now correctly?

Have you tested whatever changes you made here with the other Octave module ports? If they work as before, then let me do some testing with your changes. But, I'd like some confirmed diligence on your end before I too to much testing on my end.

I have not built all octave packages against octave-1.1.tcl. However, all the settings previously used for the configure stage have been moved to the build stage. I don't foresee any issues due to these flags. However, I plan to update all packages to the new version of the PortGroup.

[michaelld (Michael Dickens)]

Please use debug output and test the difference in *FLAGS between the PortGroups. I know that the *FLAGS are set correctly in the 1.0, but I'm not so sure they would be for your 1.1 given how the internals of 'port' work when creating those environment variables. These variables are critical to how each stage works.

[Schamschula (Marius Schamschula)]

Replying to michaelld@…:

Please use debug output and test the difference in *FLAGS between the PortGroups. I know that the *FLAGS are set correctly in the 1.0, but I'm not so sure they would be for your 1.1 given how the internals of 'port' work when creating those environment variables. These variables are critical to how each stage works.

I normally build with trace mode and verbose.

Matter of fact, that's why I got here. Without trace mode octave-tsa builds, as libgomp is not hidden.

I'll see if I can't save the debug output using octave-1.0 and octave-1.1 and do a diff.

[Schamschula (Marius Schamschula)]

Replying to mschamschula@…:

Replying to michaelld@…:

Please use debug output and test the difference in *FLAGS between the PortGroups. I know that the *FLAGS are set correctly in the 1.0, but I'm not so sure they would be for your 1.1 given how the internals of 'port' work when creating those environment variables. These variables are critical to how each stage works.

I normally build with trace mode and verbose.

Matter of fact, that's why I got here. Without trace mode octave-tsa builds, as libgomp is not hidden.

I'll see if I can't save the debug output using octave-1.0 and octave-1.1 and do a diff.

I've added fits.diff to show the differences of building octave-fits (​https://trac.macports.org/ticket/46023) using the octave-1.0 vs. octave-1.1 PortGroup.

[michaelld (Michael Dickens)]

Yeah; if you look at the diffs, you'll see all those "-" by the *FLAGS settings. That means there are no *FLAGS being set during the build phase; nor CC or CXX. Thus, stuff like the compiler to use isn't being set. Lots of stuff not being set. This is reason I went with using the configure phase for building stuff. My memory is that it should be possible to add in various "things to do" in pre-configure or the like. So, I'm not sure what your current issue is with building octave-tsa; maybe you can create a new ticket with that info? I don't think you're heading down the correct path here.

[Schamschula (Marius Schamschula)]

Replying to michaelld@…:

Yeah; if you look at the diffs, you'll see all those "-" by the *FLAGS settings. That means there are no *FLAGS being set during the build phase; nor CC or CXX. Thus, stuff like the compiler to use isn't being set. Lots of stuff not being set. This is reason I went with using the configure phase for building stuff. My memory is that it should be possible to add in various "things to do" in pre-configure or the like. So, I'm not sure what your current issue is with building octave-tsa; maybe you can create a new ticket with that info? I don't think you're heading down the correct path here.

I threw in the towel. For whatever reason MacPorts doesn't seem to have a working mechanism to pass all the configure environment variables on to the build environment variables.

So I found a kludge to work around my dilemma regarding octave-tsa:

Override the patch phase and "manually patch" the Makefile using a system call, then run the reinplace script that would have ordinarily been run as the post-patch phase from within the patch phase.

So I guess we don't need my octave-1.1.tcl, although conceptually the existing build system makes no sense at all…

[michaelld (Michael Dickens)]

I understand that the build ordering doesn't make sense. But, it works and that counts for a -lot-. And, it's not that bad, overall -- some Python ports build during configure, too, because there's little other choice. While I'd love to shift build phases around to be more logical, I hope folks can figure out the ordering -- it's not -that- far off of "the usual".

[michaelld (Michael Dickens)]

As for octave-tsa: Can you email me off of this ticket the issue with libgomp? I'll bet you can patch the primary Makefile (augmenting the current patch) instead of requiring a post-patch phase.

[michaelld (Michael Dickens)]

I'm closing this ticket as "wontfix" -- nothing personal. I love the idea, but until 'port' internals allow for each copying of the configure phase environment this won't work.