Skip to content
This repository has been archived by the owner on Sep 1, 2023. It is now read-only.

Pythonic build: Switch from cmake to distutils extensions for nupic installation #1579

Merged
merged 15 commits into from
Jan 19, 2015

Conversation

david-ragazzi
Copy link
Contributor

Fixes #1573.

This PR aims to help we have Nupic "pip installable". For this it tries to leave the build/install process the more "pythonic" as possible using:
a) native support from Distutils/SetupTools to build all C++ extensions (#1573)
b) Python scripts to perform jobs that were being performed by C++ executables (#1576).

The motivation of B is because it's very tricky install all current cpp executables and libraries using A solution. Some of these libraries (like bindings) are inevitable to be build as extensions, however c++ extensions like htmtest and compare_nupic_core_version can be replaced to python scripts. Different than bindings, these 2 extensions are complicating the process as they should be installed into souce repository (bin folder, to be exact) and not into nupic package install folder like the other modules.

Once that all extensions now can be build in a natural way, we can remove CMakeLists.txt from NuPIC Pyhton. This makes that CMake becomes essential only to build the NuPIC Core library: as this is an optional job, we could bypass CMake/Git use during PIP process decreasing the number of build/install steps and dependencies.

I still am working on the pythonic version of HtmTest. Thus it's normal that some tests fail, because Travis still is referencing its c++ version.


TODO:

  • Figure out the ARCHFLAGS="-arch x86_64" requirement on darwin64. Update: There's not way, distutils take the flags which python was build. So we cannot set this variable inside setup.py.
  • Update supporting documentation (README, wikis) with any build changes. Update: README updated with ARCHFLAGS instructions.
  • Simplification of this PR by move bindings refactoring to a new PR. Solved by Bindings refactored #1610
  • Simplification of this PR by move Travis scripts, CMakeLists.txt, and README update (replacement of make commands to python instructions and custom_targets remotion) to a new PR. Solved by Pythonize the tests calls #1622
  • Simplification of this PR by move HtmTest to nupic.core on a new PR. Solved by Remove HtmTest and call it from nupic.core binaries #1676 and Move test_py_htm to nupic.core and refactor test nupic.core-legacy#282
  • python setup.py --help & python setup.py --help-commands should print help, not compile

@david-ragazzi
Copy link
Contributor Author

CC: @rhyolight @oxtopus

@david-ragazzi
Copy link
Contributor Author

Update:

I've found these Python tests which are very similar to HtmTest:

https://github.com/numenta/nupic/blob/master/tests/integration/py2/nupic/engine/network_testnode_interchangeability.py
https://github.com/numenta/nupic/blob/master/tests/integration/py2/nupic/engine/network_twonode_test.py

I'm serioulsy thinking in remove it as it sounds very redundant.

@david-ragazzi david-ragazzi force-pushed the build_extensions branch 10 times, most recently from 311ad29 to 7d446d6 Compare December 4, 2014 23:38
if not os.path.exists(destDir):
os.makedirs(destDir)

response = urllib2.urlopen(url)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Davidragazzi You have to handle all HTTP errors here. No matter what the error, print a warning and proceed with a local clone and build of nupic.core.

@rhyolight
Copy link
Member

Here is the error I'm getting on darwin:

duplicate symbol __ZNK4YAML6Stream11GetNextByteEv in:
    /Users/mtaylor/nta/nupic/extensions/core/build/release/lib/libnupic_core.a(stream.cpp.o)
    /Users/mtaylor/nta/nupic/extensions/core/build/release/lib/libyaml-cpp.a(stream.cpp.o)
ld: 93 duplicate symbols for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
error: command 'c++' failed with exit status 1

Looks like nupic.core contains libyaml.

@oxtopus
Copy link
Contributor

oxtopus commented Dec 5, 2014

Yes, libyaml is bundled into libnupic_core.a: https://github.com/numenta/nupic.core/blob/master/src/CMakeLists.txt#L398

commonObjects = [
nupicCoreReleaseDir + "/lib/" + self.getStaticLibFile("nupic_core"),
nupicCoreReleaseDir + "/lib/" + self.getStaticLibFile("gtest"),
nupicCoreReleaseDir + "/lib/" + self.getStaticLibFile("gtest"),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Duplicate line.

@oxtopus
Copy link
Contributor

oxtopus commented Dec 5, 2014

Please see david-ragazzi#41

That builds for me on my laptop with caveats. For some reason, by default "-arch x86_64 -arch i386" is passed to clang, which causes compiler errors:

../nupic.core/release/include/nupic/math/ArrayAlgo.hpp:5256:30: error: register %rdx is only available in 64-bit mode
                     "ja 0b\n\t"                   // loop
                             ^
<inline asm>:21:7: note: instantiated into assembly here
        popq %rdx
             ^~~~
fatal error: too many errors emitted, stopping now [-ferror-limit=]
14 warnings and 20 errors generated.
error: command '/usr/bin/clang' failed with exit status 1

As far as I can tell, the only way around it is to set the env var, which is not ideal.

@rhyolight
Copy link
Member

Hey @david-ragazzi I'd like to work on this PR tomorrow (in about 8 hours). If you have local changes that are worth pushing, try to push them before then. If you're online, maybe we can work together.

@david-ragazzi
Copy link
Contributor Author

@oxtopus said:

Yes, libyaml is bundled into libnupic_core.a: https://github.com/numenta/nupic.core/blob/master/src/CMakeLists.txt#L398

Ah ok.. This answered my question in david-ragazzi#41 (comment)... I'll merge your PR now.. By the way, we still need solve this ARCH env var and avoid this. I see now that you agree that this is not ideal. So we could put a #TODO as @rhyolight suggested until we solve the other issues.

@david-ragazzi
Copy link
Contributor Author

Hey @david-ragazzi I'd like to work on this PR tomorrow (in about 8 hours). If you have local changes that are worth pushing, try to push them before then. If you're online, maybe we can work together.

It's ok for me however I'm not on my machine now, so I couldn't help pushing directly code until go home (11 am - Los Angeles time) but merging PRs into my branch and helping to solve issues until there. About this, could someone solve the merge conflicts on this PR and then send a new PR to I update my branch?

@rhyolight
Copy link
Member

@david-ragazzi said:

could someone solve the merge conflicts on this PR and then send a new PR to I update my branch?

david-ragazzi#42

@rhyolight
Copy link
Member

Current status for local darwin build: http://pastebin.com/NtDGg2Fi

Basically, this error over and over:

In file included from nupic/bindings/math_wrap.cpp:3179:
/Users/mtaylor/nta/nupic/extensions/core/build/release/include/nupic/math/ArrayAlgo.hpp:5250:49: error: register %rsi is only
      available in 64-bit mode
                     "movaps %%xmm3, 48(%%rdi)\n\t"

@oxtopus
Copy link
Contributor

oxtopus commented Dec 5, 2014

@rhyolight That is the issue that requires setting the ARCHFLAGS env variable as I described. It's not happy with the -arch i386 flag that seems to be generated automatically.

@rhyolight
Copy link
Member

@oxtopus Got it. I updated this PR with a new TODO item so we don't forget it.

@rhyolight
Copy link
Member

@david-ragazzi I'm going to start by adding HTTP error handling logic when trying to pull in nupic.core binaries.



def skipPyCompile(self, file, cfile=None, dfile=None, doraise=False):
filesToSkip = ["UnimportableNode.py"]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@oxtopus Didn't you take care of this in a recent PR?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I did, and it no longer needs to be skipped.

@david-ragazzi
Copy link
Contributor Author

Hi guys, as we are in a Python environment, could be possible set temporary ARCH in runtime using os.env?

#
if sys.version_info < (2, 7):
print "FATAL_ERROR: Only these versions of Python are accepted: 2.7 or later"
sys.exit()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of this printout and exit, I think I'd rather raise an Exception for things we define as "fatal". I'll include in a PR I'm working on.

@rhyolight
Copy link
Member

@rhyolight
Copy link
Member

@david-ragazzi david-ragazzi#51 pulls in the latest changes from master after I pushed 0.1. It includes a big README simplification, but your ARCHFLAGS instructions were moved into the wiki along with the other "build from source" instructions.

Merges in master with 0.1 README
@david-ragazzi
Copy link
Contributor Author

@david-ragazzi david-ragazzi#51 pulls in the latest changes from master after I pushed 0.1. It includes a big README simplification, but your ARCHFLAGS instructions were moved into the wiki along with the other "build from source" instructions.

Ok, it's fine.

@coveralls
Copy link

Coverage Status

Coverage remained the same when pulling 53de635 on david-ragazzi:build_extensions into d8436f1 on numenta:master.

@rhyolight
Copy link
Member

@scottpurdy ping!

nupic/bindings/*.cxx
nupic/bindings/proto/*.capnp
nupic/bindings/
~nupic/bindings/*.i
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what is ~nupic? I'm not convinced that I want this hidden from me if it gets created

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

~ = not, so these lines mean ignoring all files in nupic/bindings/, except *.i files.

@scottpurdy
Copy link
Contributor

A couple questions but I think this is good. @oxtopus was happy and I wanted to make sure that we are fitting all of our compilation steps into the "extension" framework which it looks this does cleanly.

@david-ragazzi - thanks for sticking with this one! Big change but will be very nice if we can keep this working for source or binary installations on different platforms.

@scottpurdy
Copy link
Contributor

Oh and to be clear, big 👍

@rhyolight
Copy link
Member

@david-ragazzi Please respond to Scott's comments and take a look at https://github.com/numenta/nupic/wiki/NuPIC's-Dependency-on-nupic.core... does this wiki need to be updated along with the merge of this PR?

@david-ragazzi
Copy link
Contributor Author

Please respond to Scott's comments

Done.

take a look at https://github.com/numenta/nupic/wiki/NuPIC's-Dependency-on-nupic.core... does this wiki need to be updated along with the merge of this PR?

Yeah, we need update wiki with removal of CMake after this is merged.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.02%) when pulling e66635c on david-ragazzi:build_extensions into d8436f1 on numenta:master.

rhyolight added a commit that referenced this pull request Jan 19, 2015
Pythonic build: Switch from cmake to distutils extensions for nupic installation
@rhyolight rhyolight merged commit 9f17246 into numenta:master Jan 19, 2015
@rhyolight
Copy link
Member

david-ragazzi pushed a commit to david-ragazzi/nupic that referenced this pull request Jan 22, 2015
Fixes: numenta#1573

It's weird.. I simply don't undertand why this file still is in repository. I thought I had removed it through numenta#1579
@david-ragazzi david-ragazzi deleted the build_extensions branch February 21, 2015 17:58
mihail911 pushed a commit to mihail911/nupic that referenced this pull request Aug 5, 2015
…le, dir, etc.) as well as minor alignment issues
mihail911 pushed a commit to mihail911/nupic that referenced this pull request Aug 5, 2015
Cleanup re: numenta#1579.  Fixup namespace conflicts with builtins (file, dir, ...
mihail911 pushed a commit to mihail911/nupic that referenced this pull request Aug 5, 2015
Pythonic build: Switch from cmake to distutils extensions for nupic installation
mihail911 pushed a commit to mihail911/nupic that referenced this pull request Aug 5, 2015
Fixes: numenta#1573

It's weird.. I simply don't undertand why this file still is in repository. I thought I had removed it through numenta#1579
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Put all functionally of "CMakeLists.txt" into "setup.py"
6 participants