[76337] trunk/dports/science/smodels/Portfile

[Ryan Schmidt]

On Feb 20, 2011, at 05:20, Jeremy Lavergne wrote:

>> But mightn't these reinplaces be better handled as a combo patchfile-with-placeholders / reinplace-placeholders-with-values? In particular the CXXFLAGS -- what if upstream later changes the CXXFLAGS in the Makefile slightly? Unless your MacPorts base is patched to include the patch from #15514, your reinplace will then silently fail, whereas if you use a patchfile, you'll get notification and immediate port failure, which is good because it gives you the chance to fix it; it also gives you context around the line in question, so that you can more easily find the corresponding section in the revised source file.
> 
> Sounds like we should be putting that patch into base, no? Either way, thanks for the patchfile suggestion :-)

Maybe. There are a good number of ports that currently have reinplaces that trigger the warning that patch produces. Those seem like things that should be corrected in most cases. But there are also some ports (including my mysql5, and all ports using the kde4 portgroup) that do a reinplace in a loop over many files, only some of which actually contain the text to be replaced. This can trigger thousands of these warnings. The patch also introduces a new reinplace flag ports and portgroups can use to suppress the warning, but until a version of MacPorts base is released that includes that flag, ports and portgroups can't begin to use it (unfortunately for this situation, it is a fatal error to use a nonexistent reinplace flag). Maybe we should add a dummy suppress flag to reinplace first (that would do nothing), and release a version of MacPorts with that. Then after everyone has upgraded to that version of base, we can add the suppress flag to the ports and portgroups most affected by this. Then we can add the actual warning code to base and release another version of MacPorts with that later.


>>> +use_configure       no
>> 
>> This means you'll need to manually deal with build_arch and UsingTheRightCompiler.
> 
> Unfortunately there's no configure file.

Sure; I understand why you wrote "use_configure no". Not having a configure script just comes with consequences and additional responsibilities for you.