[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GNU Autoconf 2.69] OSX autotools: `aclocal.m4' not being output by
From: |
Gary V. Vaughan |
Subject: |
Re: [GNU Autoconf 2.69] OSX autotools: `aclocal.m4' not being output by `autom4te' |
Date: |
Fri, 27 Jun 2014 11:50:47 +0100 |
Hi Jeff,
On Jun 27, 2014, at 11:10 AM, Jeffrey Sheen <address@hidden> wrote:
> Thanks for the suggestions Gary.
No problem.
> I do run a NAS on my LAN, and backup from my shared data partition to both
> Dropbox and Copy (the only cloud storage clients that support symlinks over
> multiple file system types). These both rely on network connectivity, where
> the solution I require is a partition on local drive attached to the device.
Assuming this means you need to unmount, detach, walk to another machine, plug,
mount and then access... you still have a few better options than FAT, I think.
> Is it possible to have a local, NTFS data partition and access it with Samba
> on a local boot partition? I would have thought that fundamentally you'd need
> a layer converting Samba I/O calls into NTFS calls, in which case, why not
> address the NTFS partition directly (functionality which does not exist in
> OSX).
You answered your own question :) OSX can mount windows shares, even though it
can't read an NTFS filesystem (actually I did once find a way to mount NTFS
read-only on Snow Leopard, so you might want to google that if it seems
attractive in case it is still maintained and/or improved). But again, that
requires at least an adhoc wifi network to connect the OSX client to the
Windows SMB server, which you seem to have ruled out.
> Synchronising data across multiple local partitions is certainly not more
> elegant than a single, shared data partition, and would require multiple
> times the redundancy of storage.
Well, that's hard to say without more context. But, I have all my open source
projects checked in to local git repos on a dropbox share, and use them from
dozens of heterogenous machines scattered across the globe all of which DropBox
synchronizes invisibly for me... which suits me far better than FAT + sneaker
net ;-) But, that only works because I know I'm only working on one machine at
a time and don't have to worry about merge conflicts.
> With regards to TrueCrypt and PKZip, are these not application layer
> implementations that create files on top of a file system? If this is not the
> case, and they have their own file system implementations, then let me know
> and I will test them.
They create a filesystem in a file on the host filesytem that contains contents
of the packaged files + metadata (timestamps, ownership etc). You would either
pkunzip into a local featureful filesystem, edit and then pkzip back into the
host filesystem for sneaker net transport to the next machine, or in the case
of TrueCrypt mount the embedded filesystem from either a disk image in the host
fs, or from a whole disk image -- lots of details in the TrueCrypt docs. Be
careful to avoid the deliberately brain-damaged most recent release though -
and pick up 6.1a images for all the machines that need to read the TrueCrypt fs.
> Without a viable alternative, I will continue to use a FAT data partition,
> and temporarily copy source trees onto my boot partition when executing GNU
> Autotools over them. I can then copy them back, and proceed normally.
In that case, what about hosting the transported files in a VM that boots with
virtual box or vmware (or other multi-arch compatible VM image format) on each
target machine and have the running VM export the shared files over
sshfs/samba/nfs/all-3! for live mounting and editing on the target machine?
Docker also seems to run on Windows, according to its website: So a modern
solution might be to wrap the whole thing up in a docker container on the
external drive and deploy that on each target machine in turn for access to the
files it contains. And with a little extra care you could easily incorporate
snapshotting and/or backups into the process without additional tools.
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
signature.asc
Description: Message signed with OpenPGP using GPGMail
- Re: [GNU Autoconf 2.69] OSX autotools: `aclocal.m4' not being output by `autom4te', (continued)
- Re: [GNU Autoconf 2.69] OSX autotools: `aclocal.m4' not being output by `autom4te', Eric Blake, 2014/06/20
- Re: [GNU Autoconf 2.69] OSX autotools: `aclocal.m4' not being output by `autom4te', Jeffrey Sheen, 2014/06/20
- Re: [GNU Autoconf 2.69] OSX autotools: `aclocal.m4' not being output by `autom4te', Jeffrey Sheen, 2014/06/21
- Re: [GNU Autoconf 2.69] OSX autotools: `aclocal.m4' not being output by `autom4te', Jeff Sheen, 2014/06/26
- Re: [GNU Autoconf 2.69] OSX autotools: `aclocal.m4' not being output by `autom4te', Eric Blake, 2014/06/26
- Re: [GNU Autoconf 2.69] OSX autotools: `aclocal.m4' not being output by `autom4te', Bob Friesenhahn, 2014/06/26
- Re: [GNU Autoconf 2.69] OSX autotools: `aclocal.m4' not being output by `autom4te', Jeff Sheen, 2014/06/27
- Re: [GNU Autoconf 2.69] OSX autotools: `aclocal.m4' not being output by `autom4te', Gary V. Vaughan, 2014/06/27
- Re: [GNU Autoconf 2.69] OSX autotools: `aclocal.m4' not being output by `autom4te', Werner LEMBERG, 2014/06/27
- Re: [GNU Autoconf 2.69] OSX autotools: `aclocal.m4' not being output by `autom4te', Jeffrey Sheen, 2014/06/27
- Re: [GNU Autoconf 2.69] OSX autotools: `aclocal.m4' not being output by `autom4te',
Gary V. Vaughan <=