[MacPorts] #47896: submission: cpuid
noreply at macports.org
Tue Jun 2 05:56:08 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 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
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,
> > 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
If you had googled the first sentence ("Permission to use, copy [...]")
you would have directly landed here:
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
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-
Ticket URL: <https://trac.macports.org/ticket/47896#comment:3>
Ports system for OS X
More information about the macports-tickets