Remove old build system

[david-ragazzi]

After CMake process get stable we should remove the old build system in order to reduce complexity and size, and so we have a clean house and can continue with folder restructuring and nupic.core issues.

I list some items that should be removed (suggestions are welcome):

• /build_system folder enterely.
• shell scripts at root folder (build.sh, cleandbuild.sh, env.sh)
• IDE files at root folder (Everything.xcodeproj, trunk.slni)
• Makefile.ami files spread over source folders (except those in binding folders, they are independent processes and in future we should convert them to CMake.. it is an easy job).
• buildinfo.py files spread over source folders?? Not sure about its function.

[scottpurdy]

I agree that it is good to have just one build system. Let's make sure to announce our intended date of removal of the automake build system on the list well ahead of time so that people have a chance to prepare. We should also have deprecation warnings added at the start and end of the build with the previous system.

[rhyolight]

What do you think about leaving in the build.sh and cleanbuild.sh scripts, but edit them to simply execute the proper cmake / make bash commands? Then no one has to update their local build scripts.

If we do this, I think it's important to update .travis.yml to use build.sh so there is only one process that's expected to work in both CI and by users.

[david-ragazzi]

What do you think about leaving in the build.sh and cleanbuild.sh scripts, but edit them to simply execute the proper cmake / make bash commands? Then no one has to update their local build scripts.

It is a good idea. But if we want have a cross-platform build process (I mean windows-like and other non-unix platforms), we should forget these scripts (CMake does very well all the "dirty job")..

[rhyolight]

But if we want have a cross-platform build process (I mean windows-like and other non-unix platforms), we should forget these scripts

Yes, I had not thought about that. Good point.

[subutai]

Other than Grok, is anyone else dependent on the build.sh script? If not, we can try to just change the Grok pipeline so it calls cmake and make directly instead of build.sh.

[rhyolight]

@subutai said:

Other than Grok, is anyone else dependent on the build.sh script? If not, we can try to just change the Grok pipeline so it calls cmake and make directly instead of build.sh.

I think this is the best option, although @jcasner might not be enthralled about it. Anyone else currently using build.sh will need to be warned, but they should all be on the ML where I'll make an announcement before we merge any changes that remove build.sh.

[david-ragazzi]

Hey @rhyolight and @subutai ,

It's interesting you state a deadline for this (1 week, for example). The next issues depend this issue. For example, if we restructure the repos, we would have to change CMake files and also all the old makefiles only because people still uses build.sh !!

[subutai]

@david-ragazzi You are right - it gets very time consuming and awkward. Can we work through a branch right now? I will try to see how fast we can switch the Grok pipeline over to use CMake. We just finished a release, so it is a good time to do it.

[david-ragazzi]

Can we work through a branch right now?

Yes, I'll create a branch to this..

[david-ragazzi]

I created the following branch for this purpose:

https://github.com/david-ragazzi/nupic/tree/Temp

However my current computer doesn't have GitHub software, and thus I can't delete entire folders right now. Later (at my home) I will remove the mentioned files and test with Travis.

[rhyolight]

@subutai @david-ragazzi I'm confused. Why do we need a branch on the main nupic repo instead of just working through a PR like normal? Our process states:

All other branches are considered simply feature branches, which exist within forked repositories, not within the NuPIC repo itself.

I think having branches on the main fork of the repo causes confusion and the PR model we use with Github is much cleaner. What is the benefit of this branch?

Maybe there is just confusion about a "branch on a developer fork" vs "branch on nupic".

[subutai]

@rhyolight My mistake. I meant "branch on a developer fork" and our normal PR process.

[david-ragazzi]

@rhyolight My mistake too.. I created a "Temp" branch in main repo, but I'm not able to delete it.. I created it in my fork now.. I'm sorry.. :-(

[subutai]

@rhyolight @david-ragazzi It's deleted now.

[rhyolight]

Thanks guys!

---

Matt Taylor OS Community Flag-Bearer Numenta

On Wed, Feb 26, 2014 at 8:51 AM, Subutai Ahmad notifications@github.comwrote:

@rhyolight https://github.com/rhyolight @DavidRagazzihttps://github.com/DavidRagazziIt's deleted now.

Reply to this email directly or view it on GitHubhttps://github.com/numenta/nupic/issues/673#issuecomment-36147285 .

[rhyolight]

@david-ragazzi Subutai and I have been talking about whether to leave the build.sh script or not, and here is what we've come up with.

In addition to removing all the old build stuff, we update build.sh to simply make the proper cmake calls to build. This is only temporary, and future changes will remove build.sh entirely. When someone runs build.sh, we print to stdout a warning that using build.sh is deprecated and will soon be removed, and users should follow the instructions in the README.

This is mainly to provide an incremental build change for Grok pipelines, and is really just a stop-gap measure. As soon as Grok updates pipelines, we will remove build.sh entirely.

But it also warns any current users that are not aware of any build change that their build process is deprecated and they'll need to update their process.

What do you think?

[david-ragazzi]

@rhyolight Yes, I think that this a good measure as we don't have native Windows support yet.

Furthermore, this way we don't need establish a deadline and so we can work on background.

[rhyolight]

Great! Also I want to add that .travis.yml will not change.

[subutai]

@rhyolight Should I make this change, since it is primarily a Grok/backward compatibility thing?

[rhyolight]

@subutai Yes, but in an effort to try to keep a 1v1 relationship between tickets and PRs, please attach it to #677.

[rhyolight]

Well, I guess this is closed by #687. :wink: