[WIP] Fixed installation process with the GNU Build System

[alquerci]

Q	A
Bug fix?	yes (some unexpected make behaviours)
New feature?	no
BC breaks?	no
Deprecations?	no
Tests pass?	yes
Related tickets	#66
License	GNU GPLv3

• Added to configure the check for only Python version 2.*, the version 3 is not supported.
• Deals with DOS and Cygwin program path
• Clean up .gitignore (build, dist)
• Created a batch script for Windows Python (e.g. cyg-apt.bat)

Using a custum build system is not portable and it does not have all features
that required the GNU Coding Standards.

In order to come as close as possible to the GNU Coding Standards. Using
autotools is a good practice.

There are some changes:

• the python library of this package is private so it does not install under
  the standard python site-package directory but on $(pkgdatadir)/python
  (default: /usr/local/share/cyg-apt/python)

• to build from source it requires the automake package

• the build process command line:

  Before:

  $ make
  

  After:

  $ autoreconf -i && ./configure && make
  

• the tests suite command line:

  Before:

  $ make test
  

  After:

  $ make check
  

• the installation tests suite command line:

  Before:

  $ make installtest
  

  After:

  $ make installcheck
  

[nylen]

I'm not convinced that we want to make the process of installing more complicated for our users. What benefit does adhering to the GNU coding standards give? Isn't it better overall to just have people run make && make install, than have to worry about how a configure script works?

Also, I personally am not a fan of autotools, it's really really complicated and I think it nay be too much for this project. I may just not understand the point of it though.

[nylen]

I am not trying to be harsh here, I'd like to hear your opinion on the benefits to these changes that justify the additional complexity. And I guess the user-facing install process in README.md isn't that much more complicated, I was looking at INSTALL.md instead.

[alquerci]

The point with configure is to check whether the user system is able to install cyg-apt and use it. Therefore this script checks the Python version (missing to check for only version 2), programs used and some other things required to install successfully.

It also create a config.py module that defines absolute path of gpg, mount... with dos path for a Windows Python and Cygwin path for Cygwin Python. This implementation is maybe not the better because a Windows Python cannot execute an installation for Cygwin Python with Cygwin program path, this point can be improved.

The current installation process is tricky and very bad coded for example, it does not take the correct path for programs (default path are absolute that is wrong). Moreover a custom Makefile implementation is hard to maintain.

With autotools the installation process is not so complicated but just more configurable for users if there want and more maintainable for maintainers (e.g. with make distcheck maintainers test all things).

[nylen]

Well, alright. Let me know when you think this PR is ready and I'll test it on a couple of my systems. And, please don't get hit by a bus :(

[alquerci]

I freeze the first commit for this PR at b7ac6c9 before cleaning commit history and merge it is almost ready. For one week I work only on it (cf. travis appveyor).

Indeed before merge it we need "health-insurance coverage".

Besides, there is a good tutorial that explain how autotools works (ref) it help me to understand the tool, before reading it I thought like you autotools is too complicated.

[nylen]

I still think it is pretty complicated:

But that is a really good tutorial, thanks!

[alquerci]

I am trying to resolve the executable script problem:

• shabang with a Windows Python

  #!/usr/bin/env c:/python26/python
  # /usr/local/bin/cyg-apt
  ...

  does not work because it will be the same as

  c:/python26/python /usr/local/bin/cyg-apt %*

  A Windows Python cannot interpret a Cygwin path.
  So installing for Windows Python will fail.

I don't know if the following solution is good.

There are three cases:

• installing for Cygwin Python

  $ autoreconf -i
  $ ./configure
  ...
  checking for python platform... cygwin
  ...
  $ make install
  ...
  $ ls /usr/local/bin/cyg-apt*
  cyg-apt

• installing for Windows Python

  $ autoreconf -i
  $ ./configure PYTHON=c:/python26/python
  ...
  checking for python platform... win32
  ...
  $ make install
  ...
  $ ls /usr/local/bin/cyg-apt*
  cyg-apt.bat

• installing for both Cygwin Python and Windows Python

  $ autoreconf -i
  $ ./configure
  ...
  checking for python platform... cygwin
  ...
  $ make install
  ...
  $ ./configure PYTHON=c:/python26/python
  ...
  checking for python platform... win32
  ...
  $ # will only install `cyg-apt.bat` because all overs architecture-independent files
  $ # has been installed with the previous `make install`
  $ make install-exec
  ...
  $ ls /usr/local/bin/cyg-apt*
  cyg-apt    cyg-apt.bat

Edit:
Creating symbolic link to the batch file may deal with that ln -s cyg-apt.bat cyg-apt.

Look like executable extension cyg-apt for unix and cyg-apt.exe for win. It' similar to cross compiling.

[alquerci]

This change will be merge for the version 2.0 for give us time to prepare users and finalize it.