This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Generic build script instructions


Op Fri, 18 Jun 2004 22:22:59 -0400 (EDT) schreef Igor Pechtchanski
in <Pine.GSO.4.58.0406182155360.3356@slinky.cs.nyu.edu>:
:  On Sat, 19 Jun 2004, Bas van Gompel wrote:
:
: > Op Fri, 18 Jun 2004 08:58:42 -0400 (EDT) schreef Igor Pechtchanski:
: > :  On Fri, 18 Jun 2004, Bas van Gompel wrote:
[<pechtcha at see es dot and why you dot ee dee you>]
: > : Cute, very cute...
: > Ehh... Thanks, I think.
:
:  Yeah, I just never saw this particular obfuscation before, is all. :-)

I did it by hand. (I know, I should get a job.)

[EMBI]
: > Excuse My Butting In.
:
:  Ok, this one's on its way to the OLOCA. :-D

<g>

[package maintainers]

: > I keep some packages locally, following changes are in them...
:
:  Then, as far as I'm concerned, you're a maintainer.  Any particular reason
:  for not submitting those packages, though?  License issues, perhaps?

One, (s-lang) is rather complex and I expect I could not really
support it. It also builds OOTB (sort of). (I'll consider votes an
incentive to start cleaning up my patches >:-> ). The other is just
waiting for the announced maintainer to publish his work. (core-utils)

[...]

: > The change in indentation makes the ``ispatch()'' call hard to spot,
: > hence the (botched) copy.
:
:  Why not submit two separate patches, then? ;-)

The change in indentation would still affect many lines which are not
functionally changed. (I would thus want to add a 3rd patch.)

[the purpose of "ispatch()"]
: > In other words: ``ispatch'' copies the patch generated by ``mkpatch''
: > from .sinst to ${topdir}, so it can be used now, not just get included
: > by ``spkg''.
:
:  I see.  That's not quite the way I use the gbs (I never edit the patched
:  directory, but keep the original edited version separately).

? I'm talking about when you first port the app, or when you are
changing to a new upstream version.

:    Perhaps
:  "ispatch" is not the best name for it?

Could be. You use it when you determine this _is_ the correct patch.

:    Looks like "savepatch" might be
:  better...  As I never intend to use this feature, the above is just a
:  suggestion.

I would expect that --``savepatch''-- to do st else (like store the
patch from ${topdir} someplace). But if you insist I'll change it to
that. I would prefer st different, though. (``acceptpatch'' maybe?)

: > : > : We could also try putting some more
: > : > : autodetection code into the GBS (e.g., get "make" to try both the "test"
: > : > : rule and the "check" rule -- the two most common names for running the
: > : > : testsuite -- and pick the one that exists).
: > : >
: > : > I saw a trick that might be usable for this somewhere... i'll get back
: > : > to you on it...
: > :
: > :  I think we could use something like "make -n" and check the return code...
: > :  But as I don't have the time to implement it properly now, I'll look at
: > :  whatever methods people choose to provide in their patches.
: >
: > It was something using a ``make -f -'' IIRC... (l8r)
:
:  Hmm, "make -f -" will actually not be useful, FWICS.  We want to check
:  whether the Makefile contains either a "test" or a "check" rule, whereas
:  "make -f -" will bypass the Makefile altogether.  But if I'm wrong, it
:  won't be the first time.

Found it. it uses ``-f Makefile -f -'' to get the value of
a Makefile-variable, and is of no use to us here. ``make -n''
is probably the WTG.
 
[patch-size vs. functionality]

:  Oh, I see the confusion.  I didn't mean the size of the patches that are
:  incorporated into the gbs itself -- those can be arbitrarily large.  I
:  meant the size of the patches that the packagers have to maintain
:  separately from the gbs, i.e., the things in the package build that don't
:  fit into the gbs defaults.  I think it's pretty obvious that *those*
:  should be small.

<slap target="face" subject="self"/>
Now I get it. Ofcourse. You're correct.

: > [append a (wrapped) GBS patch to the GBS]
[store gbs, before mods to CYGWIN-PATCHES]

:  Oh.  Well, again, I never store the build script into CYGWIN-PATCHES, but
:  it doesn't mean that nobody else should...  Everyone has his own methods.

I'm not saying anybody _should_, just that it will make upgrading the
specific-build-script easier.

: > Or maybe just store the diff? One could then recreate the original gbs
: > to merge against.
:
:  That's more or less what I'm proposing.  Take the (default) gbs, add a
:  section to it that does something like
:
:  (echo "--- generic-build-script
:  +++ $0"; cat <<END-OF-PATCH
:  @@ -1,100 +1,100 @@
:  - patch goes here
:  + patch goes here
:  END-OF-PATCH
:  ) | patch && exec "$0"
:
:  and let the maintainers put their patches between the "cat" and
:  "END-OF-PATCH".  At least, that's what I had in mind.  Then the set of
:  changes to the gbs can be easily extracted (and moved) to the new version.

Let me get this straight. First you take a copy of gbs. you edit it.
You make a diff against the orig gbs. you paste that diff into yet
another copy of the gbs. you then run the last one, which will then
recreate the file you had before, by editing itself inplace? _Now_ I
*am* confused.

:  Hope this clears up the confusion,

I think storing the diff in CYGWIN-PATCHES (and having it automatically
be included in foo-x.y-z.patch) is cleanest/clearest.

L8r,
-- 
  ) |  | ---/ ---/  Yes, this | This message consists of true | I do not
--  |  |   /    /   really is |   and false bits entirely.    | mail for
  ) |  |  /    /    a 72 by 4 +-------------------------------+ any1 but
--  \--| /--- /---  .sigfile. |   |perl -pe "s.u(z)\1.as."    | me. 4^re


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]