screen-users
[Top][All Lists]
Advanced

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

Re: updating the build


From: Micah Cowan
Subject: Re: updating the build
Date: Mon, 26 Jan 2009 22:21:37 -0800
User-agent: Thunderbird 2.0.0.19 (X11/20090105)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've slightly rearranged the order of your text somewhat, for my own
convenience in responding.

I apologize for taking so long to respond to your steady sets of patches
and notices on this. And particularly, for promising to set up a hosted
repository for you, and then failing to do so. :(

William Pursell wrote:
> I've been working on updating the configury for screen, and have
> gotten to a state that could reasonably be merged.  (Also, I don't
> know that I'll have much time to look at this over the next few
> months.)  Primary benefits:
> 
> Uses gnulib's getloadavg, so the configury for that function is
> up-to-date and actively maintained.
> 
> Uses config.guess to determine host and arch.  Again, the primary
> benefit being active maintenance of the checks.
> 
> Everything can be specified at configure time.  For example,
> to set USRLIMIT, the user can either do it the old way
> and edit config.h after running configure, or run configure
> with the argument "usrlimit=20".  I pick usrlimit as an
> example because both my fork and the current master
> do not compile with usrlimit set, so that leads to...

...

> This fork provides no new functionality, but is a good
> step towards bringing screen up to date.
> 
> Micah, Juergen, et al., please let me know if there
> is anything objectionable that causes you to refrain
> from merging.

Thank you very much for working on this. I think this will be extremely
useful.

We did something pretty much like this for Wget when I took on
maintenance for that project. We split off a separate repo to do this,
which was the mainline development branch; in the meantime, we kept on
working on a separate repo which lacked automake/gnulib in anticipation
of the 1.11 release. I guess it's probably high time we forked a branch
for Wget, for post-4.1.x releases; this would be a great place to put
your contributions.

I would like to get some feedback from the other maintainers about the
move to gnulib (I remember that jw approved the move to automake a while
back). We did this as well for Wget. I think it was a good move, but I
have some mixed feelings about it, too. I think mainly because gnulib
modules tend to have a lot of dependencies on other modules, so you
invevitably end up pulling in a large amount of extra code. Sometimes
the gnulib modules don't offer quite the flexibility that you need, but
you can't really modify it freely since it's just overwritten with the
next update; you can of course submit patches upstream, but in the
meantime you've got to copy it out to your own source tree and make your
modifications there (and use a different name).

OTOH, you lose the hassle of maintaining that code, and gain the
advantage of a significantly larger test base, automatically receiving
fixes for whatever bugs are inevitably found in the implementation of
these core functions. As I said, I'm still glad we did it with Wget, but
it is a mixed blessing, and I'd like to hear jw's input.

> The git repository is at:
> address@hidden:wrp/wscreen.git in branch wrp.

That failed to work for me (pub key auth failed). But
  git pull git://github.com/wrp/wscreen.git wrp
worked.

- --
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer.
GNU Maintainer: wget, screen, teseq
http://micah.cowan.name/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkl+p/AACgkQ7M8hyUobTrGtWQCeJw/YQP/NWiAQKan3yW+BMtZw
h3QAn1g9RHidrsBQo8Mz8hE+uTni5y/d
=FUYE
-----END PGP SIGNATURE-----




reply via email to

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