new port: py-khmer

[ryandesign (Ryan Carsten Schmidt)]

This project is hosted at github. Possibly using the github portgroup would simplify the portfile.

This port fetches from git. Could it fetch from a tarball instead? That would be preferred.

This port fetches the head of the git repository. That's not ok; it needs to fetch a specific version of the source so that port builds are repeatable and predictable. You've indicated in the version field that this is version 0.4, so it needs to fetch version 0.4 of the source.

This port is overwriting the portgroup's dependencies; it should append to them instead.

This port is insisting on compiling with clang. This will not work on older versions of OS X whose Xcode versions do not have clang. Please instead use compiler.blacklist to blacklist the specific compilers that don't work.

Instead of using system "cd ${worksrcpath}; make" use system -W ${worksrcpath} "make"

[larryv (Lawrence Velázquez)]

Why is it necessary to run make twice? From the source on GitHub, it seems like make all (i.e., the default build command) should handle everything. Am I missing something?

[sean@…]

I'm attempting to address this in the revision -- it's a Python project with some C libraries (outside the Python directory) that need to be built first. Looking at just running 'make' in the lib/ dir before the Python module is built. Ideally the Python build would take care of everything, but it doesn't.

Is that a suitable approach for this kind of hybrid?

[sean@…]

Remove duplicate make, use github portgroup, fetch tarball, remove specific compiler dependency, correct way to do pre-build stage?

[larryv (Lawrence Velázquez)]

Replying to sean@…:

I'm attempting to address this in the revision -- it's a Python project with some C libraries (outside the Python directory) that need to be built first. Looking at just running 'make' in the lib/ dir before the Python module is built. Ideally the Python build would take care of everything, but it doesn't.

This is the top-level makefile:

all: lib_files python_files

clean:
	cd lib && make clean
	cd python && rm -fr build khmer/*.so

doc: FORCE
	cd doc && make html

lib_files:
	cd lib && make

python_files:
	cd python && python setup.py build_ext -i

test: all
	nosetests

FORCE:

It looks like running make all from the top-level directory (i.e., the default MacPorts build behavior) should take care of both the C and Python bits. Does it not?

[sean@…]

It does build both, but there is no install target for make. Unless I misunderstand something, I don't see how this would stage any files into destroot, which is why I went the python route instead.

Replying to larryv@…:

Replying to sean@…:

I'm attempting to address this in the revision -- it's a Python project with some C libraries (outside the Python directory) that need to be built first. Looking at just running 'make' in the lib/ dir before the Python module is built. Ideally the Python build would take care of everything, but it doesn't.

This is the top-level makefile:

all: lib_files python_files

clean:
	cd lib && make clean
	cd python && rm -fr build khmer/*.so

doc: FORCE
	cd doc && make html

lib_files:
	cd lib && make

python_files:
	cd python && python setup.py build_ext -i

test: all
	nosetests

FORCE:

It looks like running make all from the top-level directory (i.e., the default MacPorts build behavior) should take care of both the C and Python bits. Does it not?

[larryv (Lawrence Velázquez)]

Replying to sean@…:

It does build both, but there is no install target for make. Unless I misunderstand something, I don't see how this would stage any files into destroot, which is why I went the python route instead.

Wait, I forgot that you’re using the python PortGroup​. In that case, you might want to override some of the defaults that the PortGroup sets.

[petrrr]

Cc Me!