@Toby (or anyone with CMake knowledge),
I have some patched SWH headers I'm working on to fix compilation on Apple
but the *#ifdef LMMS_BUILD_APPLE* is getting ignored.
I tried adding INCLUDE(DetectMachine) in CMakeLists.text to no avail.
The #ifdef is in swh/impulses/all.h
Any suggestions for what I doing wrong?
-Tres
- [email protected]
On Fri, Apr 11, 2014 at 2:06 AM, Tres Finocchiaro <
[email protected]> wrote:
> Tres maybe we should drop wine for mac and create a crossover (mac
>> equivalent which is based off wine) wrapper. That is how FL does it with
>> their software it somehow creates and bundles a crossoverwrapper to get
>> that working. and In the tutoral video alot of the vst's worked except for
>> a few.
>>
>
> Crossover is just a special build of wine and does nothing more to help.
>
> In terms of a wine wrapper, what do you think LMMS is already doing?
>
> What FL studio does is irrelevant to anything I've been asking for help on
> because we can't see their source code so we don't know how they build.
>
> We aren't having issues opening Wine, at least not yet. We're just having
> issues building against Wine which is different. Wine opens and works
> well. Once we can build against it, then we can have discussions about how
> we link and what pre-built flavors of wine we recommend.
>
> Remember, if you find software that does Windows VSTs well on *nix, then
> the software you found IS USING WINE :). CodeWeavers (the Crossover
> software you keep mentioning) was once called Crossover Office,
> specializing in Microsoft Office hacks for Wine) and is just a commercially
> repackaged version of wine. They actually contribute a lot of their FOSS
> source code upstream anyways. We are fine at least building with our
> baseline WineHQ MacPorts version which is community supported and it runs
> well on Mac. If we link against Crossover or another 3rd party it will be
> solely for the convenience to our users and shouldn't affect our building
> strategy at all.
>
> Back to why this won't build.... I believe the issues here are how Clang
> thinks win32 should be compiled. It's clear that there are some win32
> header bindings that we need to turn off (or download? :)). This is
> because Wine's winegcc binary is just a wrapper around the Clang compiler
> and Clang expects certain Microsoft Visual Studio type libraries when it
> sees the windows build flags. This probably makes perfect sense on an
> actual Win32 buld env, but likely isn't needed in our case.
>
> I do appreciate the feedback and interest. :)
>
> -Tres
>
>
>
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos. Get
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
LMMS-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/lmms-devel
