[Pkg-pascal-devel] Heads up for my changes to d/rules of fpc

[Abou Al Montacir]

Hi Paul,

On Tue, 2015-11-10 at 21:24 +0100, Paul Gevers wrote:
> Hi all,
> 
> Before I commit, I like yo to know that I have quite drastically changes
> the fpc d/rules (not yet as much as I wanted) to fix two big announces
> that I had ever since I joined the effort to work on Free Pascal.
> 
> 1) I changed the clean rules (set of targets) to now be much faster when
> you start with a fully clean tree. The problem with the old set, albeit
> being fundamentally correct, wasted a lot of time on fpcmake. I now fool
> the fpcmake targets when we start with a clean tree. The comment in the
> d/rules:
> The really correct clean target is very heavy for an already clean tree
> because it needs to regenerate all the Makefiles from Makefile.fpc files
> to be able to call all the upstream distclean targets. Therefor the
> clean target is split into multiple components and the makefiles target
> is fooled when ZERO generated Makefiles are found. I (elbrus) consider
> that a reasonable trade-off. If for whatever reason you need the real
> (and heavy) target you can run the clean-makefiles target before calling
> clean.
The way the "old" clean target was working took me too long time to achieve. I
consider that the right way to go. Sometimes one can get into horrible issues
because a clean target does not work correctly. Also how can you ensure
reproducible builds if you clean target is potentially not correct?

I agree that it could be nice if we can skip this sometimes, so I'd recommend an
environment variable that allows selecting between both behaviors while keeping
default to the old behavior.
> 
2) When something went wrong during building, most of the time calling
debian/rules binary failed to do the right thing. In the past I have too
ofter done "debian/rules clean ; debian/rules binary" wasting a lot of
time before testing a possible fix. (One of) The problem(s) was that the
binary-indep target (via install-source and clean-patched) removed all
the build code. I have resolved this issue by making sure that the
install-source target is now the first target after manipulating the
source, such that it is still clean.

That is indeed a nice feature. Is it really related to 1) or completely
independent?
> 
I haven't timed the latest build on my machine, but it felt a lot
quicker and I verified that indeed all the files were still there at the
end. So it seems that I achieved both my targets.

I hope you agree with this approach and that I can continue with
committing this to our archive
I don't fully agree but I think we can keep both as mentioned above. I hate
making people loose time, so I'll not object, but wold rather prefer to keep
both old and new behaviors if that is possibile.
-- 
Cheers,
Abou Al Montacir