[MacPorts] #47896: submission: cpuid

MacPorts noreply at macports.org
Tue Jun 2 12:59:05 PDT 2015

#47896: submission: cpuid
  Reporter:  rjvbertin@…  |      Owner:  macports-tickets@…
      Type:  submission   |     Status:  new
  Priority:  Normal       |  Milestone:
 Component:  ports        |    Version:
Resolution:               |   Keywords:
      Port:  cpuid        |

Comment (by rjvbertin@…):

 Replying to [comment:6 ionic@…]:

 >  I stopped constantly apologizing after pointing out it's just dry, not
 harsh or insulting.

 I wasn't necessarily thinking of you. In your case I simply bounced the
 ball back into your field rather than trying to figure out if I should do
 more than simply include a stub Id line. Which turned out to be enough :)

 > Yeah, I thought that too, but interestingly it lead right to the correct
 license - and I tried anyway, even with having that thought in mind. Even
 *if* multiple licenses were returned, I would have gone through them to
 find the correct one.

 Heh, and I was more or less convinced that someone on here would find the
 issue important enough maybe even to recognise the license blurb at first
 sight. Sorry it had to, correction, turned out to be you.

 > Base supports trace mode as of version 2.3.0. If you don't have that,
 you should really, really, really upgrade...

 My lazy. I have 2.3.3 and too quickly assumed that the feature was still
 available in "development builds" only. Good to know, because there have
 been times I'd have liked having it.

 > I don't think you tested everything. Including old OS X versions, new
 ones, passing combinations of long, short options with and without
 parameters and invalid options.

 No. I checked that the things I was looking for in the app worked. Truth
 be told, I half expect certain things not to work (without patching the
 code) given the nature of the beast and I hadn't even noticed that there
 was an option to use an included getopt version. Would you have raised an
 issue about getopt if that Makefile option had not been there?
 > Okay, they are shipping NetBSD's getopt. That's probably compatible

 Also check the rather basic argument list the app supports: nothing fancy
 that is likely to hinge on an exotic (or Swiss Army knife) version of
 getopt ..

 > Also move it after any modeline.

 But then `port lint` won't be happy ;)

 > I don't really like putting the replacement stuff into `configure`. It's
 really patching, not running a configure script or program. But as it's
 more or less indeed "configuring" the package, I guess we can leave it as-

 I know, but I've already seen configure scripts that do more or less the
 same thing ...

 > However, there are two problems with that: because you used
 `use_configure no`, there won't be an implicit `universal` variant. Please
 add one via `variant universal {}` after `use_configure no`.

 I'm no longer using `use_configure`?! I checked: +universal is accepted
 and leads to a universal executable.

 > Secondly, you're way overcomplicating things.
 > Drop the `variant_isset universal` check.
 > `reinplace` `-Os` with `${configure.cppflags} ${configure.cflags}
 [get_canonical_archflags cc]`

 Hmm, so `configure.universal_cppflags` is never used (I noticed it was
 empty during my tests)?

 > and
 > `LDFLAGS := -lm` with `LDFLAGS := -lm ${configure.ldflags}
 [get_canonical_archflags ld]`
 > Make sure to not drop `-lm` again!

 Are you sure? I don't think that's required even on Linux anymore. It
 certainly didn't prove to be required (or else I'd have left it in).

Ticket URL: <https://trac.macports.org/ticket/47896#comment:7>
MacPorts <https://www.macports.org/>
Ports system for OS X

More information about the macports-tickets mailing list