Re: Legacy Support for GHC-Based Projects

2023-01-17 Thread Steven Smith
A stack binary is required to build stack, and to the best of my knowledge there is no ppc stack binary: https://github.com/commercialhaskell/stack/search?q=ppc=. I recommend such requests be taken upstream, as there is no “fix” for PPC on our end.Back to topic, is anyone able to confirm that stack-based pandoc is working (or not) on a legacy platform also supported by stack back to Sierra?On Jan 17, 2023, at 09:08, Sergio Had  wrote:





If PPC is fixed on our end, I will try to upstream patches, so we won’t need to carry those.

On Jan 17, 2023 21:47 +0800, Steven Smith , wrote:


To clarify, the question is how to specify that these ports use the latest stack version for builds on legacy systems. Does it work for pandoc now?

stack on ppc or other very old non-supported systems will be extraordinarily fragile and time-consuming, and I expect difficult to anticipate sustained MacPorts support, especially as stack migrates to arm.

On Jan 17, 2023, at 08:39, Sergio Had  wrote:





I assume stack-based builds are still broken for PPC, as well as Intel builds on 10.6.8, but I will try to find time to work on fixing it. Ken kindly shared his work on GHC for Snow Leopard, but it is for x86 (and not in Macports).

If anyone is good at cross-compiling, please ping me. We need to first build the latest GHC on 10.6.8 Intel and then cross-compile GHC for PPC.

On Jan 17, 2023 06:15 +0800, Steven Smith , wrote:
I recently added legacy-based support to pandoc, but I’m not sure that the code I used is working. I’ll issue a revised PR based on any feedback and use a working version for other GHC-based projects.


I used this code to force stack-based builds on macOS versions that predate Apple Silicon. After Apple Silicon, we need cabal-based builds for native binaries.










set arm64_minimum_supported_major_version 20



if {${os.platform} eq {darwin}



&& ${os.major} < ${arm64_minimum_supported_major_version}} {



# use stack to build x86_64 binaries



default_variants-append \



+stack



}





stack-based stack builds work all the way back to Snow Leopard: https://ports.macports.org/port/stack/details/. I’d expect the same of pandoc, but it only builds back to Sierra: https://ports.macports.org/port/pandoc/details/



Is anyone able to suggest profile code that will accomplish this? Is this related to the design choice to use a the port variant +stack to specify the build tool?










smime.p7s
Description: S/MIME cryptographic signature


Re: Legacy Support for GHC-Based Projects

2023-01-17 Thread Sergio Had
If PPC is fixed on our end, I will try to upstream patches, so we won’t need to 
carry those.
On Jan 17, 2023 21:47 +0800, Steven Smith , wrote:
> To clarify, the question is how to specify that these ports use the latest 
> stack version for builds on legacy systems. Does it work for pandoc now?
>
> stack on ppc or other very old non-supported systems will be extraordinarily 
> fragile and time-consuming, and I expect difficult to anticipate sustained 
> MacPorts support, especially as stack migrates to arm.
>
> > On Jan 17, 2023, at 08:39, Sergio Had  wrote:
> >
> > I assume stack-based builds are still broken for PPC, as well as Intel 
> > builds on 10.6.8, but I will try to find time to work on fixing it. Ken 
> > kindly shared his work on GHC for Snow Leopard, but it is for x86 (and not 
> > in Macports).
> >
> > If anyone is good at cross-compiling, please ping me. We need to first 
> > build the latest GHC on 10.6.8 Intel and then cross-compile GHC for PPC.
> > On Jan 17, 2023 06:15 +0800, Steven Smith , wrote:
> > > I recently added legacy-based support to pandoc, but I’m not sure that 
> > > the code I used is working. I’ll issue a revised PR based on any feedback 
> > > and use a working version for other GHC-based projects.
> > >
> > > I used this code to force stack-based builds on macOS versions that 
> > > predate Apple Silicon. After Apple Silicon, we need cabal-based builds 
> > > for native binaries.
> > >
> > > > set arm64_minimum_supported_major_version 20
> > > > if {${os.platform} eq {darwin}
> > > > && ${os.major} < ${arm64_minimum_supported_major_version}} {
> > > > # use stack to build x86_64 binaries
> > > > default_variants-append \
> > > > +stack
> > > > }
> > >
> > > stack-based stack builds work all the way back to Snow Leopard: 
> > > https://ports.macports.org/port/stack/details/. I’d expect the same of 
> > > pandoc, but it only builds back to Sierra: 
> > > https://ports.macports.org/port/pandoc/details/
> > >
> > > Is anyone able to suggest profile code that will accomplish this? Is this 
> > > related to the design choice to use a the port variant +stack to specify 
> > > the build tool?


Re: Legacy Support for GHC-Based Projects

2023-01-17 Thread Steven Smith
To clarify, the question is how to specify that these ports use the latest stack version for builds on legacy systems. Does it work for pandoc now?stack on ppc or other very old non-supported systems will be extraordinarily fragile and time-consuming, and I expect difficult to anticipate sustained MacPorts support, especially as stack migrates to arm.On Jan 17, 2023, at 08:39, Sergio Had  wrote:





I assume stack-based builds are still broken for PPC, as well as Intel builds on 10.6.8, but I will try to find time to work on fixing it. Ken kindly shared his work on GHC for Snow Leopard, but it is for x86 (and not in Macports).

If anyone is good at cross-compiling, please ping me. We need to first build the latest GHC on 10.6.8 Intel and then cross-compile GHC for PPC.

On Jan 17, 2023 06:15 +0800, Steven Smith , wrote:
I recently added legacy-based support to pandoc, but I’m not sure that the code I used is working. I’ll issue a revised PR based on any feedback and use a working version for other GHC-based projects.


I used this code to force stack-based builds on macOS versions that predate Apple Silicon. After Apple Silicon, we need cabal-based builds for native binaries.










set arm64_minimum_supported_major_version 20



if {${os.platform} eq {darwin}



&& ${os.major} < ${arm64_minimum_supported_major_version}} {



# use stack to build x86_64 binaries



default_variants-append \



+stack



}





stack-based stack builds work all the way back to Snow Leopard: https://ports.macports.org/port/stack/details/. I’d expect the same of pandoc, but it only builds back to Sierra: https://ports.macports.org/port/pandoc/details/



Is anyone able to suggest profile code that will accomplish this? Is this related to the design choice to use a the port variant +stack to specify the build tool?






smime.p7s
Description: S/MIME cryptographic signature


Re: Legacy Support for GHC-Based Projects

2023-01-17 Thread Sergio Had
I assume stack-based builds are still broken for PPC, as well as Intel builds 
on 10.6.8, but I will try to find time to work on fixing it. Ken kindly shared 
his work on GHC for Snow Leopard, but it is for x86 (and not in Macports).

If anyone is good at cross-compiling, please ping me. We need to first build 
the latest GHC on 10.6.8 Intel and then cross-compile GHC for PPC.
On Jan 17, 2023 06:15 +0800, Steven Smith , wrote:
> I recently added legacy-based support to pandoc, but I’m not sure that the 
> code I used is working. I’ll issue a revised PR based on any feedback and use 
> a working version for other GHC-based projects.
>
> I used this code to force stack-based builds on macOS versions that predate 
> Apple Silicon. After Apple Silicon, we need cabal-based builds for native 
> binaries.
>
> > set arm64_minimum_supported_major_version 20
> > if {${os.platform} eq {darwin}
> > && ${os.major} < ${arm64_minimum_supported_major_version}} {
> > # use stack to build x86_64 binaries
> > default_variants-append \
> > +stack
> > }
>
> stack-based stack builds work all the way back to Snow Leopard: 
> https://ports.macports.org/port/stack/details/. I’d expect the same of 
> pandoc, but it only builds back to Sierra: 
> https://ports.macports.org/port/pandoc/details/
>
> Is anyone able to suggest profile code that will accomplish this? Is this 
> related to the design choice to use a the port variant +stack to specify the 
> build tool?