Add 64bit handling about apt

[amr66]

Yeah! Another step to 1.0! Good job, Matt!

[maphew]

I think sharing cache folder is fine, maybe even a good idea. Theoretically it would allow cache to be on a shared network drive and used across multiple machines.

I tried running one o4w shell session and then setting a new osgeo4w_root variable somewhere else. It fails (I think) because it reads setup.rc from the current shell and not from the new root var.

B:\osgeo4w_32> set osgeo4w_root=c:\OSGeo4W64

B:\osgeo4w_32> apt list
error: C:\Users\Matt\AppData\Local\Temp/http%3a%2f%2fdownload.osgeo.org%2fosgeo4w%2f\x86/setup.ini no such file
error: set OSGEO4W_ROOT and run "apt setup"

Intution tells me that more work on moving the too-many-globals into local functions, something I'd really like to do anyway, might help with this. Not something I'm going to attempt right now though ;-)

[maphew]

Yay! We have a working test to match setup.ini's bitness to the command line:

:: osgeo4w_root=d:\osgeo_32

X:\> apt --arch=x86_64 list
error: Architecture mismatch! Setup.ini: 'x86', Command line: 'x86_64'

but, a new bug discovery. This should also fail but doesn't:

X:\> apt --arch=X86_64 list
Package             Version
------------------  ----------
msvcrt              1.0.1-13
msvcrt2008          1.0-1
msvcrt2010          1.0-1
setup               1.0.7-13
shell               1.0.0-15

It's because the --arch flag handling is case sensitive. I didn't tackle that because I'm I'd like to explore using the filename option instead. The general idea:

• create a hard link so the file contents are the same, and editing one edits the other

  B:\code\apt> mklink /h apt-64.py apt.py
  Hardlink created for apt-64.py <<===>> apt.py

• Add a new function that extracts 64 from the filename and reacts accordingly.

However I've hit the end of my time available for now, and don't know when I'll be able to follow up.

---

PS: thanks for rebooting my interest in apt :) I do hope that in my enthusiasm I didn't get in your way! I have a tendency to do that and often don't notice until too late. :-/

[amr66]

Don't worry, I'm glad you spent your sparce time. I expect more interest in x64 software for the future and i plan to have my portable version in 64bit in some near(?) future when all (windows) operating systems are 64bit ;-)

[maphew]

and, pre-release! https://github.com/maphew/apt/releases/tag/v4

Before going to full release I'd like to see if we can make apt smart enough to detect the bitness from current OSGEO4W_ROOT, after initial setup has been run, so that --arch=X86_64 isn't needed on every invocation.

[maphew]

0e315fa determines bitness from apt filename.
Note: this breaks --arch parameter.

Contrary to my earlier comment, we want a symlink and not a hard link. With a hard link reverting to an earlier version, e.g. hg/git revert breaks the link and the contents are no longer identical. So:

mklink apt-64.py apt.py

---

As I write this I realize this solution is more complicated than what I wrote earlier today: "detect the bitness from current OSGEO4W_ROOT". So today's work successfully implemented the idea from 11 days ago, but should be thrown out in favour of today's idea. I should do a better job of listening to the current moment and not the past! ;-)

[maphew]

Re: commit 8d89884 - We always read arch setting from setup_ini, consequently apt setup now requires --arch flag . There is no default.

apt --arch x86_64 setup

This simplifies things, as now the flag is only every used once during initial setup, and all other times we rely on a a single source: setup.ini.

[maphew]

Released as v0.4! https://github.com/maphew/apt/releases

Thank you for your help @amr66! Sincerely appreciated.

[maphew]

:) It does make me wonder: what does apt need to look like to be "1.0 worthy"?

Maybe it's already there; version numbers are free after all. I guess I've been keeping it low because I feel like such a programming novice and that it would be overly boastful to claim higher.