[fpc-devel] Proposal to adapt search patch under Haiku using a target specific option (-WH).

[Florian Klämpfl]

Am 30.12.2018 um 14:58 schrieb Olivier Coursière via fpc-devel:
> Some background :
> 
> Haiku currently supports two compilers toolchains with two sets of libraries and ABI for its 32 bits flavor :
>  - gcc 2 for BeOS compatibility
>  - gcc 4 (or above : currently 7.3) for newer libraries like Qt (and Lazarus).
> 
> The default gcc toolchain can be changed using a command line : setarch currently accepting x86_gcc2 or x86.
> Once this is done, the only practical difference from Freepascal point of view is that the search patch should be
> adapted to use the rights libraries according to the context.
> 
> A few years ago, i have open the bug 26486 (https://bugs.freepascal.org/view.php?id=26486) with a first proposal that
> was too hacky to be committed. Since then, i have made another proposition involving a new command line switch to let
> specifying the set of search paths when targeting gcc4. This alternative proposal got unnoticed since then.

To me, the -WH approach looks reasonable. IMO it can be integrated into trunk.

> 
> I am currently looking at packaging Lazarus for Haiku and it would simplify the process a lot in our Haikuports system
> (our equivalent of Ports in FreeBSD).
> 
> So here is the proposal :
> 
> I propose to add a -WH option that can accept a "gcc4" parameter to specify the alternative option. This is similar to
> others -W options used to specify the kind of applications on the same platform (like -WA or -WG for Windows).
> It would simplify lazarus building under Haiku using a command like that :
> 
> make LCL_PLATFORM=qt OPT="-WHgcc4"
> 
> Do you think that kind of options could be upstreamed ? If so, i can update the patch to match current sources and maybe
> use the same option names as setarch to specify the platform.
> 
> If not, i can still patch freepascal sources before packaging freepascal for Haiku through our haikuports system. But it
> would be, in my opinion, less practical on the long term.
> 
> Or maybe someone will come up with a better idea to handle that kind of problems ?
> 
> What do you think about this proposal ?
> 
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel