# Python Ports



## dchappelle (Jan 8, 2009)

I have downloaded and compiled both the 2.6 and 3.0 Python source. I noticed a few things:

    1. The Makefile does not include any of the port /usr/port/Mk/* files.

    2. There is no build option or relevant pkg_create files for bundling python into a freebsd package.

Is there a specific reason for this? How difficult would it be to make the necessary changes?

I also noticed that the binary Python download is installed as a Freebsd package via pkg_create. Am I missing something here?


----------



## hydra (Jan 9, 2009)

I have no idea what are you talking about. Python is in /usr/ports/lang/python26 and python30, respectively. In order to install any of them, move to that directory and type in 'make install clean'.


----------



## dchappelle (Jan 9, 2009)

What I want to be able to do is type:

    ./configure ...
    make
    make package

and have a package created that I can use with pkg_add. I have multiple machines to install on and I don't want to have to do a build on each one just so that I can install. Also, as new machines are brought online, I don't want to have to rebuild every time. Many of the other FreeBSD ports have this feature in their makefiles (ie. .include /usr/ports/Mk/...). There are a ton of files that are installed when you do a 'make install' so writing my own pkg_create files will likely be painfull. The binary python tarballs are compatible with pkg_add so someone must have already went through the pains of packaging it.


----------



## hydra (Jan 9, 2009)

Ok, so: cd /usr/ports/lang/python26 && make package, what is the problem ? Or you may even download the packages from FreeBSD mirrors.


----------



## hark (Jan 9, 2009)

dchappelle said:
			
		

> The binary python tarballs are compatible with pkg_add so someone must have already went through the pains of packaging it.


What binary Python tarballs? Python is only officially distributed in binary format for Windows, AFAIK.



> What I want to be able to do is type:
> 
> [red]./configure ...[/red]
> make
> ...


If you're making packages, you should be using ports, which means *not* using the configure (or any other build/install) scripts which are included with the official release. Ports wraps all of the build up, such that you only interact with the port's Makefile.

To configure the port, use make config. This gives you access to a couple of options (which get passed to configure when the port is built). If you need options which the Makefile does not make available, you can hack them in by adding the appropriate strings into the CONFIGURE_ARGS variable within the port's Makefile. For example, if you wanted to build with Py_DEBUG (a configure option available in Python 2.6 which isn't exposed by the Makefile), a quick hack would be to just add the line CONFIGURE_ARGS+= --enable-pydebug. A more robust approach would be to add a new option, but it probably isn't necessary if you're just going to build once and redistribute the package.

You can sometimes get away with re-running the configure script _after_ the Makefile does, such that it builds with the options you configure it with. The downside here is that you might overlook and overwrite something that the Makefile does and end up with a broken binary.

ie,


```
cd /usr/ports/lang/python26
make config
./work/Python-2.6/configure
make package
```

In any case, if you're using configure args which aren't exposed by the Makefile, you might end up with a binary which doesn't work -- only the options available in the Makefile are typically "guaranteed" to work. With some of the more exotic options available, you might find cases which require patching the application's source before it builds/runs properly.


----------



## kamikaze (Jan 9, 2009)

hark said:
			
		

> What binary Python tarballs? Python is only officially distributed in binary format for Windows, AFAIK.


Have you by any chance _not_ read chapter 4 of the handbook? I would especially recommend you chapter 4.4.


----------



## hark (Jan 10, 2009)

kamikaze said:
			
		

> Have you by any chance _not_ read chapter 4 of the handbook? I would especially recommend you chapter 4.4.


I have -- I just don't consider binaries distributed outside of python.org to be "official" :3


----------



## kamikaze (Jan 10, 2009)

They are the official FreeBSD binaries. People have put effort into making sure they work with FreeBSD.


----------

