Re: [Jython-dev] Reworking build.xml

[Jeff A. <ja...@fa...>]

Oti:

Nice to hear from you as I know your prints are on this from way back. 
As I understand it, -Dhas.repositories.connection=false would let me use 
the checked-out copy from an initial full-build. I think that does still 
work, in itself, but a few other things don't, and I find them hard to 
debug in that configuration.

I'm pursuing the idea that the build should occur in normal checkout 
directory: a fresh one, not where I've previously done development. I 
tend to do these from a local, never-modified, clone of 
hg.python.org/jython, to spare the upstream server and for reliability. 
Being clear in the instructions that a build properly for release must 
be from fresh, and putting in some simple safeguards, will control the 
risk of building from a polluted state (is the idea I'm testing).

Meanwhile I can hack at it and run full-build as much as I like, 
breaking the above rule (making only snapshot installers), knowing that 
I'm testing the release process we eventually use when building 
seriously. I only see a few small obstacles (e.g. the checked-out 
README.txt is modified in situ) and I know what to do about them.

Jeff Allen

On 21/08/2019 06:34, Oti wrote:
> Hi Jeff
>
> I think you are completely right that checking out makes only sense 
> for doing a release full build.
> If you want a full build from your local sources, without a checkout, 
> you can define
>
>
> # - set this to false if you want the full build run from the checked 
> out sources
>
> has.repositories.connection=false
>
>
> in the file 'ant.properties' just beside 'build.xml'.
>
> Thats the way I always did it.
> I hope this still works for you.
>
> Best wishes,
> Oti.
>
> On Mon, Aug 19, 2019 at 9:31 AM Jeff Allen <ja...@fa... 
> <mailto:ja...@fa...>> wrote:
>
>     There are swathes of build.xml I've never really understood. Many are
>     bits that have to work to make a release (full-build). A lot of
>     this is
>     good, but somewhat buggy, and it has been "particularised" to
>     releases
>     in the past, by which I mean what might have been general-purpose
>     logic
>     has become hard-coding of the answer for that particular release,
>     presumably to work around some shortcoming in the logic.
>
>     It is difficult to debug the full-build target because it checks
>     out a
>     fresh copy of the repo and works on that. This is slow, and in my
>     experience frail. It also means that when testing some hacky idea, it
>     (or parts of it) have to be pushed to the official repo. I think
>     this is
>     how the particularisations got into the official copy.
>
>     So I'm trying the idea of full-build without the checkout. It's
>     quite a
>     big change to build.xml. Building a release from the directory
>     where you
>     do development is a bad idea, I know, because there are always extra
>     files lying around that can get incorporated, or might be
>     necessary to
>     make it work, but you didn't check in. For the same reason, it is
>     good
>     routinely to have an integration workspace to which you pull
>     before you
>     push: with git it is a topic branch of your personal repo.
>
>     I think that for a release, one would always check out to a clean
>     workspace, so it is not necessary to have the script do it. I have
>     incorporated tests to warn us when it is not clean (hg status, etc.),
>     and then one can only build a "SNAPSHOT". Apart from these tests, the
>     whole script gets somewhat simpler. Or maybe I just understand it
>     better.
>
>     I may have missed an important reason why we did the checkout
>     elsewhere:
>     do say if you know it.
>
>     As always, this is turning up lots of things I never knew or noticed.
>     E.g. have you noticed "ant clean" doesn't do a complete job these
>     days?
>     Not for me, anyway. I'm left with some editor droppings that have
>     accumulated in my build/dist directories. They prevent a complete
>     clean
>     because of
>     https://ant.apache.org/manual/dirtasks.html#defaultexcludes .
>     And I have figured out the intended template processing of
>     README.txt so
>     it need not be kept in sync manually.
>
>     I just thought I'd say on the list what I'm up to.
>
>     -- 
>     Jeff Allen
>
>
>
>     _______________________________________________
>     Jython-dev mailing list
>     Jyt...@li...
>     <mailto:Jyt...@li...>
>     https://lists.sourceforge.net/lists/listinfo/jython-dev
>
>
>
> -- 
> http://ohumbel.me