Re: Reworking build.xml

Jeff Allen <[email protected]>
Newsgroups gmane.comp.lang.jython.devel
Message-ID <[email protected]>
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 <[email protected] 
> <mailto:[email protected]>> 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
>     [email protected]
>     <mailto:[email protected]>
>     https://lists.sourceforge.net/lists/listinfo/jython-dev
>
>
>
> -- 
> http://ohumbel.me

_______________________________________________
Jython-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jython-dev
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.