search

CNMAT / CNMAT-odot

Multi-paradigm Dynamic Programming
Other
115 stars 11 forks source link

dependency wrangling #371

Closed ilzxc closed 3 years ago

ilzxc commented 6 years ago

Hello :)

I've tried to rebuild odot from scratch after purchasing Max 8 just now. Seems like it's a good time to prune the projects a bit:

  1. in the odot project, we have dangling dependencies on
    • ../max6-sdk
    • ../max-sdk/c74support
    • ../c74support
  2. I've not managed to build libomax until I manually removed all #include <Carbon/Carbon.h> preprocessors and ensure that in addition to the above we have ../max-sdk/source/c74support

None of this is too big of a deal (I just ended up copying c74support in all the places it would look for it, which was the easiest way to solve for broken links). I am happy to set some time aside to ensure that both libomax and odot are looking for the c74support in one canonical place, but before I do, I wanted to make sure that there's agreement as to where that should be.

In my mind, the only sensible option is to clone cycling74's max-sdk mirror at the same level as libo and odot and update all paths to ../max-sdk/src/c74support

ramagottfried commented 6 years ago

hi @ilzxc ! for now best to run make from the src directory for a working build.

do you get errors there?

but yes, we should clear out all the max6 references, I've been doing it as I work on the objects, but in general run make when I need to build the repo.

cheers!

ilzxc commented 6 years ago

This was all done with the command line. My current SDK is 10.14 due to Xcode taking an update. The Carbon include was a hard error causing libomax builds to fail (note that removing the carbon include builds without complaints, but I have no way of testing if that's actually right because Xcode 10 doesn't want to build odot due to #372.

ramagottfried commented 6 years ago

So has Xcode 10 removed the Carbon from the Frameworks folder?

ilzxc commented 6 years ago

For libo issues after update:

ilyarostovtsev@Ilyas-MacBook-Pro ~/D/c/c/libomax> make

******************************************************************
*****                    BUILDING LIBOMAX                    *****
******************************************************************
clang -arch i386 -arch x86_64 -O3 -funroll-loops -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -mmacosx-version-min=10.9 -std=c99 -I../max-sdk/source/c74support/max-includes -I../max-sdk/source/c74support/msp-includes -I../pure-data/src -I../libo -I/usr/include  -o omax_util.o -c omax_util.c
In file included from omax_util.c:32:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/Carbon.framework/Headers/Carbon.h:34:10: fatal error: 
      'CarbonSound/CarbonSound.h' file not found
#include <CarbonSound/CarbonSound.h>

I commented out #include <Carbon/Carbon.h> from all of the libo c files and it seems to be compiling with a handful of warnings but no errors that I can tell.

Note that libopd is unaffected by these issues.

ilzxc commented 6 years ago

The issue persists both if using the default "give me the latest SDK" alias (MacOSX.sdk, default in libomax Makefile) as well as the explicit MacOSX10.14.sdk, just in case that's a question for anyone.

ilzxc commented 6 years ago

Running make for odot just calls xcodebuild on all targets, so it's identical to building with Xcode, just heedlessly.

ramagottfried commented 6 years ago

see also #367

equilet commented 5 years ago

I'm on OSX 10.14.2 attempting this. When I comment out the Carbon.h includes (thanks for this tip, @ilzxc) I have a remaining issue, which is that I get the following error:

In file included from omax_util.c:53:
./omax_util.h:43:10: fatal error: 'm_pd.h' file not found
#include "m_pd.h"
         ^~~~~~~~
1 warning and 1 error generated.

Now, if I simply comment the ifdef regarding OMAX_PD_VERSION out of omax_util.h, I get further in the build process, but then I get a host of errors regarding type identifiers:

omax_util.c:63:41: error: unknown type name 't_float'; did you mean 'float'?
extern void atom_setfloat(t_atom *atom, t_float f);
                                        ^~~~~~~
                                        float
omax_util.c:63:13: error: conflicting types for 'atom_setfloat'
extern void atom_setfloat(t_atom *atom, t_float f);
            ^
../max-sdk/source/c74support/max-includes/ext_obex.h:1243:11: note: previous declaration is here
t_max_err atom_setfloat(t_atom *a, double b);
          ^
omax_util.c:64:13: error: conflicting types for 'atom_setlong'
extern void atom_setlong(t_atom *atom, long l);

...etc....
1 warning and 13 errors generated.

Does anyone else have this issue?

ramagottfried commented 5 years ago

Looks like you need the pd source — I’m going to be going through this setup too (next week after the holidays) so I’ll report back when I have more practical info.

Sent via satellite

Am 21.12.2018 um 23:14 schrieb Jeffrey Lubow notifications@github.com:

I'm on OSX 10.14.2 attempting this. When I comment out the Carbon.h includes (thanks for this tip, @ilzxc) I have a remaining issue, which is that I get the following error:

In file included from omax_util.c:53: ./omax_util.h:43:10: fatal error: 'm_pd.h' file not found #include "m_pd.h" ^~~~ 1 warning and 1 error generated.

Now, if I simply comment the ifdef regarding OMAX_PD_VERSION out of omax_util.h, I get further in the build process, but then I get a host of errors regarding type identifiers:

extern void atom_setfloat(t_atom atom, t_float f); ^~~ float omax_util.c:63:13: error: conflicting types for 'atom_setfloat' extern void atom_setfloat(t_atom atom, t_float f); ^ ../max-sdk/source/c74support/max-includes/ext_obex.h:1243:11: note: previous declaration is here t_max_err atom_setfloat(t_atom a, double b); ^ omax_util.c:64:13: error: conflicting types for 'atom_setlong' extern void atom_setlong(t_atom atom, long l);

...etc.... 1 warning and 13 errors generated.```

Does anyone else have this issue? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

equilet commented 5 years ago

I'm not specifying that PD gets built when I invoke make.

ramagottfried commented 5 years ago

ok, just getting started on a clean Mojave install and got the odot build process working.

libopd gets built also when you run the libomax makefile, so you still need the pd source, here's the link: https://github.com/pure-data/pure-data (put in the same folder with the max and libo sdk as usual).

I had to comment out all of the Carbon.h #includes in libomax -- my guess is that we can safely take these out now... although I hesitate, in case they're needed to run with Max 6? (is anyone still on Max 6?).

Then I also had to open the Xcode project and ran the suggested project updates, and auto-scheme creation.

and then also had to set all of the build targets (the build-all, build-deprecated, etc.) Base SDK settings to be just MacOS (not MacOS 10.7).

And I had to get the max6-sdk also, although I think probably we should get updated everything to be max-sdk now.

and now finally everything builds for me.

hope that helps!

happy almost 2019!

equilet commented 5 years ago

Thx. There should be a mention of the pure data dependency in the build instructions of libomax. This wasn't always the case, and there is nothing telling the user otherwise in the readme. I don't think we should be supporting anything earlier than M7 at this point. I can update the md file in a sec...

equilet commented 5 years ago

going back to @ilzxc's original post, I think I need to spend some time working out the transition to removing the m6 dependency. More soon... I've currently removed max6 references from the xcode project and am working to iron out the kinks.

equilet commented 5 years ago

OK, I think I've accounted for everything, and it's building fine here. If I push this, does anyone want to volunteer to test on their machine?

maccallum commented 3 years ago

This issue is ancient, and everything's currently building on all supported platforms, so I'm closing.