Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#38198 closed submission (fixed)

New port: libCUDF

Reported by: cooljeanius (Eric Gallager) Owned by: neverpanic (Clemens Lang)
Priority: Normal Milestone:
Component: ports Version: 2.1.3
Keywords: Cc:
Port: libCUDF

Description

I saw cal linked to this when he was updating the GSOC wiki page, so I thought it would be useful at least to have a port for the library contained in the link. (portfile is attached)

Attachments (1)

Portfile (1.5 KB) - added by cooljeanius (Eric Gallager) 12 years ago.
portfile for libCUDF

Download all attachments as: .zip

Change History (8)

Changed 12 years ago by cooljeanius (Eric Gallager)

Attachment: Portfile added

portfile for libCUDF

comment:1 Changed 12 years ago by cooljeanius (Eric Gallager)

I originally had a +native variant that built C bindings to it, but I couldn't get it to work, so I ended up leaving that out. Also I meant to make this openmaintainer but I forgot.

Edi: See this portfile's history on GitHub: https://github.com/cooljeanius/LocalPorts/commits/master/devel/libCUDF/Portfile

Last edited 12 years ago by cooljeanius (Eric Gallager) (previous) (diff)

comment:2 Changed 12 years ago by neverpanic (Clemens Lang)

Owner: changed from macports-tickets@… to cal@…
Status: newassigned

I'll take a look. Thanks for the work so far.

comment:3 Changed 12 years ago by neverpanic (Clemens Lang)

Commited in r103436 with a couple of changes:

  • In order to make the build reproducible (i.e., always produce the same result no matter when you run it), we can not directly track development versions
  • Fetching from tarball avoids a git dependency
  • Added livecheck
  • Split the ocaml part and the C bindings part into two subports, renamed the ocaml part to ocaml-cudf.
  • Avoided manually moving the files from /usr to $prefix by patching Makefile.config -- it seems that's what it's for
  • Set $CC to use the right compiler (see UsingTheRightCompiler)
  • Added a comment that parallel building fails
  • Tests don't have to be run in the build phase, we have a dedicated test target for that. Unfortunately, we don't have depends_test, which makes the variant necessary, if we want to avoid the dependency.

Note that we don't actually have to use libCUDF to use CUDF-based solvers for MacPorts in GSoC. The file format is so simple we can generate it without the library. Having the port around might still come in handy to verify correctness of the generated files, though.

Last edited 12 years ago by neverpanic (Clemens Lang) (previous) (diff)

comment:4 Changed 12 years ago by neverpanic (Clemens Lang)

Resolution: fixed
Status: assignedclosed

comment:5 Changed 12 years ago by neverpanic (Clemens Lang)

Cc: cal@… removed

comment:6 in reply to:  3 ; Changed 12 years ago by cooljeanius (Eric Gallager)

Replying to cal@…:

Commited in r103436 with a couple of changes:

A "couple"? lol

  • Split the ocaml part and the C bindings part into two subports, renamed the ocaml part to ocaml-cudf.

Sweet, I had been trying to do that but couldn't get it to work

  • Avoided manually moving the files from /usr to $prefix by patching Makefile.config -- it seems that's what it's for

Good idea, that's probably the better way to do it

Is that necessary for the ocaml part? Or just the C part?

  • Tests don't have to be run in the build phase, we have a dedicated test target for that.

Really? I had kind of wanted them to run automatically when using the +tests variant, but whatever...

Unfortunately, we don't have depends_test, which makes the variant necessary, if we want to avoid the dependency.

I think I might open a separate ticket for this; I already opened a similar one one asking for a similar depends_pkg type of dependency (That one's #38112 for reference)

Edit: new separate ticket for this issue open: #38208

Last edited 12 years ago by cooljeanius (Eric Gallager) (previous) (diff)

comment:7 in reply to:  6 Changed 12 years ago by neverpanic (Clemens Lang)

Replying to egall@…:

Is that necessary for the ocaml part? Or just the C part?

Probably just the C part, doesn't hurt to do it for both, though.

Really? I had kind of wanted them to run automatically when using the +tests variant, but whatever...

That's not really how we have done things to far. That might make sense, but then it should better be implemented in base (e.g., by providing a switch that will always build and run the tests if there are any).

Unfortunately, we don't have depends_test, which makes the variant necessary, if we want to avoid the dependency.

See https://lists.macosforge.org/pipermail/macports-dev/2013-February/022145.html where Ryan suggested a different solution I implemented in r103439 and r103441.

Edit: new separate ticket for this issue open: #38208

Thanks.

Note: See TracTickets for help on using tickets.