gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Gnu-arch-users] Dirname caching for leroy's tla on cygwin


From: Parker, Ron
Subject: RE: [Gnu-arch-users] Dirname caching for leroy's tla on cygwin
Date: Fri, 2 Jul 2004 11:02:05 -0500

> From: John Meinel [mailto:address@hidden

> I thought the whole point of out of tree builds is that it doesn't do
> this. But it sounds like it might just be patch not properly 
> supporting
> out of tree builds.

This is likely since patch was originally using very old version of the
autotools, and I had to update it to the newer ones in order to integrate it
with package-framework.

> Well Leroy did the change for adding {revlibs} as a path that gets
> compressed. My work around was to just call my revlib 
> "{archives}". I'll
> probably switch with the new release. I probably wouldn't use 
> =dirnames,
> because a revlib wouldn't have it there to start with. Although I
> suppose you could always 'touch `tla my-revision-library`/\=dirnames'

That would be trivial to integrate, but eventually I would like to move away
from being locked into the hard coded {archives} and {revlibs} pathnames on
Windows.

> Do people use remote revlibs? I could see a Samba shared source
> checkout, but I didn't think a revlib would be used that way. I don't
> think revlibs are multi-process safe, so two people working 
> on it at the
> same time would cause problems.

I could see my development group possibly using a local and a remote revlib
so that only one person has to patch up to the current version and the rest
can just pull the files from the remote revlib.  Our check in rate would not
compare with gcc or the kernel, but in a given development cycle there are
hundreds to (low) thousands of check ins and no one is going to want to
patch forward on a new check out and burn their local drive space for a
complete local revlib.  There may be other solutions to this issue, but this
is one possible approach.

> I do like the idea that =dirnames signals to whatever arch is running
> that it should switch modes. Especially if your idea is to 
> allow people
> to publish pathcompressed archives. The only problem is 
> knowing that you
> should create the =dirnames in the first place.

My thinking had more to do with developing a package on Windows, tar'ing up
the source hierarchy and posting that to the net for others to download and
use.  It would be nice if a Linux/BSD/etc. box could still understand the
prepackaged {arch} directory.  This goes along with the fork-submit
discussion that has been kicked around of late.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]