[Pkg-pascal-devel] Bug#887575: Bug#887575: Bug#887575: Bug#887575: castle-game-engine FTBFS with fpc 3.0.4

[Abou Al Montacir]

Hi Michalis,
On Thu, 2018-01-18 at 20:56 +0100, Michalis Kamburelis wrote:
> 2018-01-18 14:44 GMT+01:00 Abou Al Montacir <abou.almontacir at sfr.fr>:
> > Doing
> > 
> >   ./fpmake --globalunitdir="/usr/lib/fpc/3.0.4"
> > 
> > Why do we need this? FPC should use the /etc/fpc.cfg to get this, why do we
> > need to explicitly pass this?
> > 
> 
> Hi Abou,
> 
> I think you're very right here -- the option "--globalunitdir XXX"
> should not be needed at all. Specifying $FPCDIR / --globalunitdir
> should only be necessary when the FPC is installed in some custom,
> user-owned location. But when the FPC is installed system-wide (like
> from a Debian package), then nothing (including CGE build script)
> should need to define $FPCDIR or use "--globalunitdir" anymore -- it
> should be picked up by the fpmake system automatically. That's how it
> should work in the upstream FPC, and I know there's an auto-detection
> in fpmkunit for these paths. So, it would be best to fix this issue,
> by fixing that auto-detection mechanism.
I fully agree, I'll try to fix that.
> To be clear: It's not just a matter of having correct /etc/fpc.cfg --
> the fpmake also needs to know the root location of FPC units. (You
> would have to ask fpmake authors why they did it like this.) But that
> is why we have this complication with $FPCDIR or --globalunitdir or
> auto-detecting it.
I've not been fan of fpmake, and I was used to compile my programs directly
using fpc prog.pas.
I understand one need to have some tool to build big projects, but then why not
lazbuild.
OK I'll stop complaining and try to fix this.
> So, we should get to the point where CGE (or any other package
> using fpmake) can be compiled by simple
> 
> ~~~
> unset FPCDIR
> fpc fpmake.pp
> ./fpmake # without any additional options like --globalunitdir
> ~~~
Yes, right!
> Looking in the FPC sources, the auto-detection is inside
> packages/fpmkunit/src/fpmkunit.pp , in TFPCDefaults.CompilerDefaults ,
> I'm quoting the relevant lines below. So, someone should adjust it (in
> Debian package) to follow the Debian path conventions :)
Wow! Thanks for this pointer, this saves me valuable time looking where to look
for the bug!
> That's a much better solution than both of my previous suggestions -- thanks!
> 
> ~~~
> procedure TFPCDefaults.CompilerDefaults;
> var
>   BD : String;
> begin
>   inherited CompilerDefaults;
> 
>   // Use the same algorithm as the compiler, see options.pas
> {$ifdef Unix}
>   BD:=FixPath(GetEnvironmentVariable('FPCDIR'), False);
>   if BD='' then
>     begin
>       BD:='/usr/local/lib/fpc/'+FCompilerVersion;
>       if not DirectoryExists(BD) and
>          DirectoryExists('/usr/lib/fpc/'+FCompilerVersion) then
>         BD:='/usr/lib/fpc/'+FCompilerVersion;
%s|usr/lib/fpc|usr/lib/' + FCompilerTargetTriplet + '/fpc|g
>     end;
> {$else unix}
> ...
> ~~~

-- 
Cheers,
Abou Al Montacir

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-pascal-devel/attachments/20180119/e728ab50/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-pascal-devel/attachments/20180119/e728ab50/attachment-0001.sig>