libftdi-0.19, fix lib64, site-packages, docs

[2bits]

This commit updates to version 0.19, changes lib64 to lib for the
library install, adds the optional deps on doxygen and graphviz,
automatically builds the python bindings if Homebrew python is
installed, corrects the location of site-packages to Homebrew's
/usr/local/lib/python2.7/site-packages, and installs the docs.
This compiles without error on 64bit OSX using XCode-4.0.2 and
llvm, gcc, or clang.

[jacknagel]

#{HOMEBREW_PREFIX}/lib/python2.7/site-packages

[2bits]

Thanks @jacknagel. Amended commit to use HOMEBREW_PREFIX/lib/python2.7/site-packages

[2bits]

bump @ a month +/- a few naps. I guess these are big changes, but I think I handled the issues that were raised.
This compiles on Lion with both compilers from XCode-4.2 (4D502). Good times lol.

[jacknagel]

Sorry, I've been swamped lately. Will try to get to this over the weekend.

[jacknagel]

@adamv Can you review the site-packages part of this?

[jacknagel]

@2bits re: the site-packages bit, the PySide formula sniffs for the installed Python version:

def which_python
  "python" + `python -c 'import sys;print(sys.version[:3])'`.strip
end

and uses that to figure out where the site-packages directory is, which is nice because it works even in the absence of a Homebrew-built Python. So we could do something like:

inreplace 'bindings/cmake_install.cmake', '/usr/site-packages', lib+"#{which_python}/site-packages"

untested, of course. Sorry for not thinking of this earlier.

[2bits]

The above commit now uses which_python to determine the site packages location.
Thanks for the suggestion.

[2bits]

I think the answer is that it wants to write to /usr/site-packages if it uses the system python, and that is off-limits.

[adamv]

Needs to be rebased on master again (sorry.)

[2bits]

Yeah, I have no idea what I just did. I gave it a

git checkout upLftdi
git rebase master
git add Library/Formula/libftdi.rb
git rebase --continue

It looks messed up, the commit.

[jacknagel]

Looks like there was a conflict that needed resolving.

[2bits]

How do I fix that if you have time for the gory details?

[jacknagel]

When you perform a "mergy" operation (in this case, forward porting earlier work onto an updated upstream with git rebase), if there are conflicts at the content level, git will punt and ask you to resolve them manuallly. In the case of rebase, the conflicts will look like this

<<<<<<< HEAD
foo
=======
bar
>>>>>>> your commit

To resolve them, just edit the file, choosing whichever content is correct, or a combination of the two, or none at all. To mark it as resolved, you git add the file and then git rebase --continue. If you add a file that still contains conflict markers, git won't stop you, as it doesn't care what the contents are.

That being said, you can still edit the file, fix it, git add and git commit --amend as usual.

[jacknagel]

To resolve them, just edit the file

I should note that you can also at this point invoke git mergetool instead of editing the file manually. I have no idea what the default mergetool on OS X is, though.

[2bits]

Ok that should be clean. It audits ok.

[2bits]

@jacknagel have a moment for this one?

[jacknagel]

I am totally out of the loop when it comes to "where to put which python stuff" these days, and as such I'm not comfortable pulling it myself; @adamv @Sharpie - any comments?

[jacknagel]

Also, can LIB_SUFFIX be set by e.g. -DLIB_SUFFIX= (I have no idea, just wondering)?

[2bits]

Thank you for asking, but no there is no CMakeCache entry for LIB_SUFFIX. Also there is no manual override code inside CMakeLists.txt. Seeing as I had it dep on Graphviz, it's broken because that requires xcodebuild, I just found out.

[2bits]

That removes the dep on graphviz for now and fixes the Dir.chdir.

[jacknagel]

So since I've asked for others to review this a few times without any response, I decided to just rebase and merge it myself.

However, this inreplace failed:

inreplace 'bindings/cmake_install.cmake', '/usr/site-packages', "#{lib}/#{which_python}/site-packages"

Otherwise I'm content to merge.

[2bits]

Adam bumped it to 0.20 two days ago, but I had some bad code in there about python. It will take some work. I think I'll just close this, and make a fresh start on 0.20.