[110106] trunk/dports/math/octave-devel/Portfile

[Jeremy Huddleston Sequoia]

+jmr to get his attention regarding the conflicts and description handling of the recipe.

Response inline below.

On Aug 26, 2013, at 18:42, Michael Dickens <michaelld at macports.org> wrote:

> On Mon, Aug 26, 2013, at 04:15 AM, jeremyhu at macports.org wrote:
>> Revision 110106
>> Author: jeremyhu at macports.org
>> Date: 2013-08-26 01:15:41 -0700 (Mon, 26 Aug 2013)
>> Log Message: octave-devel: Use fortran recipe like octave
> 
> I just updated my local SVN repository of MacPorts, then went and built
> "port" fresh and installed it so I know it is the latest and greatest
> ("port version" verifies this, since I use my own local versioning).
> 
> When I do "port variants octave-devel" I see the variants but no
> descriptions for the +gcc4X ones, nor conflicts or so forth. Further, I
> can pick multiple of the +gcc4X variants; the highest numbered "X" wins
> out -- but, only one +gcc4X variant should be allowed at a time and port
> should handle the conflicts. These results say to me that this commit,
> while well intentioned, has flaws.

Regarding your changes, it would be better to discuss these on the mailing list first, so all ports can benefit from what the issues you uncover.

Regarding descriptions and conflicts, I'm not sure why they're not showing up.  They certainly are listed, and the intent is there.  When I tested the initial version of the recipe, the conflicts certainly worked, but perhaps they stopped working when I reordered some things to get it working better.

I specifically used multiple variant lines rather than constructing one variable listing all the conflicts because that way caused the system to think the entire list of variants was a single variant name.  For example, this is from the old mpich (prior to my changes) which tried this:

~/src/macports/dports/science/mpich $ port lint
--->  Verifying Portfile for mpich
Warning: Variant clang conflicts with non-existing variant clang31 clang32 clang33 clang34 gcc43 gcc44 gcc45 gcc46 gcc47 gcc48 gcc49 llvm
Warning: Variant clang31 conflicts with non-existing variant clang clang32 clang33 clang34 gcc43 gcc44 gcc45 gcc46 gcc47 gcc48 gcc49 llvm
Warning: Variant clang32 conflicts with non-existing variant clang clang31 clang33 clang34 gcc43 gcc44 gcc45 gcc46 gcc47 gcc48 gcc49 llvm
Warning: Variant clang33 conflicts with non-existing variant clang clang31 clang32 clang34 gcc43 gcc44 gcc45 gcc46 gcc47 gcc48 gcc49 llvm
Warning: Variant clang34 conflicts with non-existing variant clang clang31 clang32 clang33 gcc43 gcc44 gcc45 gcc46 gcc47 gcc48 gcc49 llvm
Warning: Variant gcc43 conflicts with non-existing variant clang clang31 clang32 clang33 clang34 gcc44 gcc45 gcc46 gcc47 gcc48 gcc49 llvm
Warning: Variant gcc44 conflicts with non-existing variant clang clang31 clang32 clang33 clang34 gcc43 gcc45 gcc46 gcc47 gcc48 gcc49 llvm
Warning: Variant gcc45 conflicts with non-existing variant clang clang31 clang32 clang33 clang34 gcc43 gcc44 gcc46 gcc47 gcc48 gcc49 llvm
Warning: Variant gcc46 conflicts with non-existing variant clang clang31 clang32 clang33 clang34 gcc43 gcc44 gcc45 gcc47 gcc48 gcc49 llvm
Warning: Variant gcc47 conflicts with non-existing variant clang clang31 clang32 clang33 clang34 gcc43 gcc44 gcc45 gcc46 gcc48 gcc49 llvm
Warning: Variant gcc48 conflicts with non-existing variant clang clang31 clang32 clang33 clang34 gcc43 gcc44 gcc45 gcc46 gcc47 gcc49 llvm
Warning: Variant gcc49 conflicts with non-existing variant clang clang31 clang32 clang33 clang34 gcc43 gcc44 gcc45 gcc46 gcc47 gcc48 llvm
Warning: Variant llvm conflicts with non-existing variant clang clang31 clang32 clang33 clang34 gcc43 gcc44 gcc45 gcc46 gcc47 gcc48 gcc49
--->  0 errors and 13 warnings found.

> Although I appreciate all of the changes going on behind the scenes to
> get libgcc, libstdc++, and so forth standardized across compilers, I
> wish folks would verify changes like this one before committing.

I did verify that they worked earlier, and this was discussed quite a bit on the list.  I'm sorry that there are bugs, but that is why I requested a review and why I pinged the list again when I got back silence.  There are real problems here that need to be addressed very soon, and if the maintainers aren't going to respond to provide input, then I'm going to do my best to fix the issues.

> I, as
> the primary maintainer, now get to go back and undo/redo those changes,
> which were not even -my- changes, to get things working again properly.

Yes, and I suggest you discuss these with the list because the issues you are seeing are due to the recipe in general (which is used by many ports) and not something specific to your port.

> Would this have happened if I were the sole maintainer, no
> "openmaintainer" along with me? That would help me feel better about the
> way MacPorts commits work. - MLD

Non-openmaintainer ports can still get touched by other developers to address build failures as well as changes that the maintainer has been told about but which he/she did not respond to.  Both of these cases apply to these changes, and I've been pushing these changes to non-openmaintainer ports that are failing to build (or whose dependents fail to build because of the issue).  Please join the "Fortran Recipe" thread on macports-dev to discuss the issues you have run into, and hopefully we can figure out a solution to the description and conflicts problem.

Thanks,
Jeremy

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4145 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20130827/ec856697/attachment.p7s>