#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