[MacPorts] #47896: submission: cpuid

[MacPorts]

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

Comment (by ionic@…):

 Replying to [comment:2 rjvbertin@…]:
 > Replying to [comment:1 ionic@…]:
 >
 > Just a thing: this is (to be) an openmaintainer port, so anyone can feel
 free to make changes they see fit. I don't have commit permissions anyway.

 Yes, but you're submitting a new port and we're reviewing it. Suggested
 changes should be applied by the submitter and the input is meant as a way
 of learning how "stuff is done", not to annoy anyone.


 > > Missing Id line.
 >
 > This is a new Portfile written from scratch, not a fork of anything
 existing. If that line isn't generated automatically, what should I put on
 it?!

 `# $Id$`

 If this line is set (and it really should be), it will be replaced by
 subversion on checkout with the "correct" long value (revision, author,
 time...)


 > > This is not a license.
 >
 > There's only this to work with:
 > [...]
 > I have no idea if that's an existing license and how it's called if so.
 I could call it the cpuid license or I can remove the license line
 completely.

 If you had googled the first sentence ("Permission to use, copy [...]")
 you would have directly landed here:
 https://en.wikipedia.org/wiki/ISC_license

 It's the ISC license.


 > > `long_description` messed up.
 >
 > In what sense? Prints well enough here...

 There's at least one `\n` that shouldn't be there. We normally don't
 expect empty lines in `long_description` or `description`.


 > > `PortGroup` should come (directly) after `PortSystem`. I'm surprised
 this even works.
 >
 > Fortunately that's not true: there are many ports that include
 portgroups in variants or subports. That wouldn't be possible if PortGroup
 should come *directly* after PortSystem.
 > I like to organise Portfiles by section, with everything related to
 fetching grouped together after name, version and metadata.

 True, but the github `PortGroup` sets a few defaults which are meant to be
 overridden later. That's why it's preferred to be "included" early.


 > > Misses a dependency on `libgnugetopt`. Should not use the internal
 version => `NO_GNU_GETOPT`.
 >
 > It doesn't. It uses an internal version if NO_GNU_GETOPT is set, but I
 don't see any evidence that that's the case. Build as is, the binary
 doesn't depend on a getopt (or any other) library (and I'd prefer it that
 way).

 Err, yes, `NO_GNU_GETOPT` shouldn't be set. Have you tested building this
 in trace mode? Note that OS X only ships BSD getopt and while that may
 even compile, there's no saying it behaves correctly at run time.

 `libgnugetopt` should probably be added as a `lib` or `build` dependency,
 depending on how the software uses it exactly.


 > > What the hell is CHUD? We probably don't want this either.
 >
 > CHUD is sadly RIP; it was used in Shark, and here to emulate
 pthread_setaffinity_np().  It's not being linked anyway because the test
 whether to link CHUD fails.

 Well, there isn't a "test" per-se, only a test whether the variable
 `USE_CHUD` is defined and not empty. Presumably that's okay for now, but
 this behavior might change at a later time and this is meant as a heads-
 up.

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