TBH, I think the real issue here is external compatibility. End users need to know if their version is going to have the externals they need. Given how often external libraries get abandoned, the need for re-compilation is a non-trivial issue.
I think this puts me in favor of clear separation. I'm relatively agnostic as to specific names. On Thu, 8 Jun 2023 at 14:24, IOhannes m zmölnig <zmoel...@iem.at> wrote: > Am 8. Juni 2023 11:15:17 MESZ schrieb Lucas Cordiviola < > lucard...@hotmail.com>: > >How hard it would be to have both apps together in a single "Pure data" > package: > > > > Interesting idea. > > Esp for the windows packages (both the zip and the installer) I think that > would make a lot of sense. > > For the macOS app, I don't know whether it will work (but of course the > downloadable dmg could provide both apps, and it might compress well enough > that the additional content won't be a problem) > > On Linux I prefer to split rather than merge, so I'm pretty sure I will > package them separately on Debian > > > >$ pd > > > >$ pd64 > > > > But if course the two packages will be co-installable. > Depending on user demands, I might also consider pulling in the > double-package via a "soft" dependency. > > > >Oh no, compilation will be complex. > > Not really. > You basically have to build twice... > > I don't think that the standard building workflow should be adjusted for > the special case of building both variants (though now that I've written > that, it's probably simple enough...) > > > > > mfg.sfg.jfd > IOhannes > > > _______________________________________________ > Pd-dev mailing list > Pd-dev@lists.iem.at > https://lists.puredata.info/listinfo/pd-dev > -- GPG Public key at http://cyber-rush.org/drr/gpg-public-key.txt
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
