New Ticket     Tickets     Wiki     Browse Source     Timeline     Roadmap     Ticket Reports     Search

Ticket #28811 (closed submission: fixed)

Opened 3 years ago

Last modified 3 years ago

splash @1.14.1 new portfile

Reported by: daniel.price@… Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version: 1.9.2
Keywords: maintainer Cc: pixilla@…, ryandesign@…
Port: splash

Description

Dear macports folks,

I've written a Portfile for SPLASH - a visualisation tool I develop for (mainly astrophysical) simulations using the Smoothed Particle Hydrodynamics method.

Website here: http://users.monash.edu.au/~dprice/splash/

Portfile is attached, I've checked it today with the latest macports and seems to still work.

Category is science/graphics.

Would be very grateful if someone could commit this to the main macports index. I am happy to be the port maintainer (I am the main splash developer).

Cheers,

Daniel Price

Attachments

Portfile (2.8 KB) - added by daniel.price@… 3 years ago.
port file

Change History

comment:1 Changed 3 years ago by ryandesign@…

  • Port set to splash

Suggestions:

  • remove the devel and have_gfortran variants; we don't do those kinds of things in MacPorts;
  • don't use bin:-style dependencies; use port:-style;
  • remove the main build dependency on gcc44 and gcc44 reference in the default build.cmd; let those details be handled in the gcc* variants;
  • are all the read_* variants necessary? (if so, don't they conflict with one another?) Fewer variants is better;
  • list the license as "GPL-2+";
  • remove the md5 checksum;
  • remove the revision and epoch lines;
  • put a blank line between the $Id$ line and the PortSystem line

Changed 3 years ago by daniel.price@…

port file

comment:2 follow-up: ↓ 3 Changed 3 years ago by daniel.price@…

OK, here is a revised portfile. Changes:

  • devel and have_gfortran variants removed
  • bin: -> port: style dependencies
  • removed stuff in default build.cmd related to gcc44
  • grouped the read_* variants into just two mutually incompatible groups "read_extraformats1" and "read_extraformats2"
  • licence fixed
  • md5 checksum removed
  • revision and epoch removed (see question below)
  • blank line added

One questions on removing the epoch: My understanding of this is that if (say) I update the version to 2.0, it would come "before" 1.14.1, so I need an epoch there to get the ordering correct. So is the right thing to do just to add an epoch field when I do eventually release 2.0?

thanks,

Daniel

comment:3 in reply to: ↑ 2 Changed 3 years ago by ryandesign@…

Replying to daniel.price@…:

One questions on removing the epoch: My understanding of this is that if (say) I update the version to 2.0, it would come "before" 1.14.1, so I need an epoch there to get the ordering correct. So is the right thing to do just to add an epoch field when I do eventually release 2.0?

MacPorts definitely knows that "2.0" comes after "1.14.1" as you would expect, so you do not need an epoch for that. You only need to add an epoch when version numbers ever seem to go "backwards" when considered according to the normal dotted-decimal numbering scheme used by most software. Examples:

  • when upgrading from a release candidate to a final version (e.g. "2.0" should be greater than "2.0-rc2" but MacPorts doesn't think so, so you need to increase the epoch)
  • when upgrading software that uses floating-point version numbering, like Perl modules (e.g. "1.2" should be greater than "1.14")
  • when upgrading software that uses DCVS revision hashes as version numbers (e.g. perhaps "6b786dae" should be greater than "8e81aee7")

comment:4 follow-up: ↓ 7 Changed 3 years ago by daniel.price@…

thanks.

I also should check that the way I've handled gfortran is OK.

Basically, all I need is a gfortran present, and "at least" v4.2. I don't know if there is a better way of doing this than having all the possible gcc variants. A better way would be that it should install a gfortran if none is present in macports, but accept whatever is there so long as it is recent enough. Any suggestions here? \

Otherwise hopefully the port is ready to go.

comment:5 Changed 3 years ago by daniel.price@…

we seem to have gone quiet here... any chance the port can be committed now?

comment:6 Changed 3 years ago by daniel.price@…

could someone please commit this port?

thanks,

Daniel

comment:7 in reply to: ↑ 4 Changed 3 years ago by pixilla@…

Look at these ports that set fortran flags (configure.f90).

port cat adaptor
port cat miriad
port cat mpich2

comment:8 Changed 3 years ago by daniel.price@…

OK, thanks. I had a look at the ports mentioned. They handle the gcc variants in pretty much the same way I have done, so am happy with the Portfile as it is.

(that is, please commit it to the repository)

Daniel

comment:9 Changed 3 years ago by daniel.price@…

sorry to nag, but *please* can someone commit this now. It has been 4 weeks since the last request and there are no further changes.

thanks,

Daniel

comment:10 Changed 3 years ago by daniel.price@…

could someone please commit this Portfile into the Ports tree? It has been 3 months now.

comment:11 Changed 3 years ago by ryandesign@…

  • Status changed from new to closed
  • Cc pixilla@…, ryandesign@… added
  • Resolution set to fixed

Brad committed this port in r79469. I had several comments and questions about it, asked on the mailing list.

comment:12 Changed 3 years ago by jmr@…

For future reference, it's not realistic to expect that anyone will see a comment on a ticket unless they are in Cc or are the owner (or reporter) and thus get email. Post to the macports-dev list if a ticket seems to have been forgotten.

Note: See TracTickets for help on using tickets.