Re: [Quilt-dev] Re: My current quilt 0.21 :)

[James Rowe]

Hey,

  A lot of this is also a response to Martin's mail, I am just being
lazy.

On Thu, 30 Jan 2003 13:52:43 +0100
Andreas Gruenbacher <address@hidden> wrote:

> >   It would be really nice for to have named tagged to the items in
> > TODO, so you see quickly that nobody else is working on that
> > particular item.
> 
> I'd prefer a short note on quilt-devel for nontrivial stuff; tagging
> the TODO seems more appropriate for somewhat bigger changes.

  Just some way of doing, that is all that matters.

> >   I really need prettier support for a global out of tree quilt data
> > source, so that is the highest thing on that list for me(unless of
> > course 'Test if patches/ can be moved with environment variable as
> > planned.' wasn't referring to that. But still... before I carry on I
> > need to reiterate some points from a unanswered mail last week.
> 
> Well, $PATCHSCRIPTS _should_ allow to move the patches/ directory 
> anywhere you like; it just is untested. I think it makes no sense to 
> allow moving the .pc directory around at all; it is anyways associated
> 
> closely with the working tree all the time. If you think differently
> we might discuss this.

  The use of $PATCHSCRIPTS appears to be broken here, I am going to have
a proper look after I've finished a couple of other things.  There is a
large chance it is related to the non-GNU version of sed I am
unfortunately stuck using for the next hour or so, so I don't want to
make any kind of sweeping statement about it.

  In my opinion $PATCHSCRIPTS, with a name change to mirror quilt,
should be a global storage point for patches from all your projects.  ie

$PATCHSCRIPTS directory |--     efx             --      patches
                                                |--     linux           --      
patches
                                                |--     quilt           --      
patches
                                                |--     webhost --      patches

 [ note to self: use a non-proportional font in your MUA ]

  So when you are working in ~/dev/shell/quilt for example your
$PATCHSCRIPTS directory is assumed to be $PATCHSCRIPTS/quilt(
just a simple $PATCHSCRIPTS/${PWD##*/}).  Of course, this isn't even a 
remotely fool proof method, so perhaps setting a per project extension
in .pc would be a better idea. Like in~/dev/shell/quilt/.pc/.quilt have
'ROOT=$PATCHSCRIPTS/quilt'. Now I have written that out it strikes me
that it could be a much better way to do, which would solve the problems
you would have when you are using a lndir'd scratch pad and wish to
quickly commit changes back.

  As I have said in previous mails, the reasoning behind this is at work
I export my $QROOT(the name my $PATCHSCRIPTS changed to) directory
across the network so other people can add/check/fix/remove things.  I
also find it much easier to work this way when it comes to working
off-site, it is a trivial affair to pull all current projects patches
into a tarball and move them on to the laptop too.

> >   I am going to continue supporting the autotools build system
> > locallly, as much for portability as, for sensibility during
> > install.
> 
> What is autotools? Do you mean GNU Autoconf?

  This is a work-ism, I meant autoconf/automake.  I just get so used to
addressing it that way everyday that I never think.  No doubt work-isms
will appear in other things too :/

> > Perl location, patch location/version(especially for systems like
> > Solaris, or users who have a 2.0.x) and to a lesser extent bash(if
> > you count SGI box I am exporting this sylpheed to now) are some of
> > the immediate issues. Of course, these issues can be achieved with
> > the current static Makefile with some effort, but personally I don't
> > think it is the way to go.
> 
> I have added some more substitutions in the Makefile. You could write
> a configure.ac to find out the paths to the utilities. (Some things
> like cp are not substituted.)

  I am writing a configure.in and the associated Makefile.am's now.  I
am just waiting on a mail back from a friend at work,  so I can find out
which GNU patch versions need atleast a AC_MSG_WARN.

  With respect to the removal of the interpreters name does anybody
have a problem with including the emacs mode identifier in the headers? 
Possibly vim's too, but I don't use it so wouldn't now which ':vim set'
options you have to use.  I am using emacs' automode database anyway,
so this isn't really an issue for me.  But I can see it being useful in
the long run.

> >   The portability issue applies to a few other areas in quilt too,
> > specifically tempfile creation(but that is an issue for a mail after
> > I get my work done).
> 
> Tempfile creation could be abstracted intp patchfns for example. I
> don't know well enough what Solaris etc. provide for that, so I'd
> better leave that to you. (But note that some temp must live on the
> same file system as the files themselves to allow a rename.)

  There is also a small side effect of slackware's madness, the
included mktemp never had support for directory creation(used in
quilt/diff.in).  I am not sure if this applies to any other current
linux distributions. I know it doesn't apply to anything else I use, but
still as of slackware's bin-8.3.0-i386-3 package(from 8.1) it does.

  I wonder if a better linux default might be GNU's tempfile?  I've
never seen a directory incapable version of that.   Andreas has the
better idea really anyway, disassociate the usage from the creation with
a generate_temps or whatever in patchfns.

  It wasn't so much about non-linux in this case, there is also no real
exit case when a tempfile creation failed with permission problems or
whatever.  Again this would be a simple check to add from within a
generate function, and without splurging out all over the place.

  So, right now the methods that need support as far as I am concerned
are mktemp, tempfile and perhaps a...

while :
do
        spin=$RANDOM    #random instead of simply cycling should be a little 
quicker
                                        #and safer in the long run.
                [ ! -f $temp_dir/quilt.$$.$spin ] && \
                temp_name=$temp_dir/quilt.$$.$spin && break
done

  type of thing.  The other difference in there using $temp_dir, is
because a quick '[ -d ~/tmp ] && temp_dir=~/tmp || temp_dir=/tmp' test
could be a real improvement not least to protect me from the wrath of
my sysadmins when I orphan 100 files in /tmp ;). There is also the
possibility that/tmp/$USER is normally used supposed to be used.

  There is supposed to be an environment variable used anyway, but all
too often it hasn't been set anyway.

> >     And again, quilt should be outputting full --help information
> >     but I
> > would like to see some agreement on this before I implement it.
> 
> What exactly do you have in mind? I was thinking of a wrapper that
> gives one-line information on each command, but adding an option to
> each script for printing a one-line description seemed too messy for
> what it would bring.

  Pretty much the exact same thing.  I should have put it in to words in
the first place.

  Anyway, I am wasting time describing things when I should be
writing/posting them for approval/rejection ;)  So, I am off to sync up
with CVS and continue.

Jay

-- 

www.jnrowe.uklinux.net
GnuPG key fingerprint = 7721 D12B 822B 20FE FCE6  B2B7 7CDF C9DF D16A
87D7

pgprsxEwVZaF1.pgp
Description: PGP signature