Autotools are not aware of ObjectiveC

[mojca]

Describe the bug

When building Audacity on macOS with a configure script rather than Xcode, some files are not built correctly due to the use of ObjectiveC. (The Xcode project explicitly marks those files as ObjectiveC, but automake doesn't know anything about the file types.)

The autotools would probably at least need to define AC_PROG_OBJC, but further changes might be needed. A quick-and-dirty workaround for us was to rename some files from .cpp to .mm, but that's probably not suitable to be upstreamed as these files are regular C++ files for any other platform. Another dirty workaround might be to simply always add -ObjC when using wxWidgets with Cocoa.

Clang as the default compiler on macOS builds ObjectiveC if one either passes the -ObjC compiler flag, or if the file ends with a suitable extension.

Even if the CMake support gets added, the problem will not simply disappear as CMake would call the compiler based on file ending as well.

The list of affected files is roughly the following:

src/KeyboardCapture
src/VSTControlOSX
src/commands/CommandManager
src/effects/Effect
src/effects/lv2/LV2Effect
src/menus/WindowMenus

A slightly related problem is the following piece of code blindly assuming that everyone using VST must be using GTK. We work around it by replacing VSTControlGTK.cpp with VSTControlOSX.mm, but this needs some conditional on WXMAC as well.

if USE_VST
audacity_CPPFLAGS += $(VST_CFLAGS)
audacity_LDADD += $(VST_LIBS)
audacity_SOURCES += \
	effects/VST/aeffectx.h \
	effects/VST/VSTEffect.cpp \
	effects/VST/VSTEffect.h \
	effects/VST/VSTControlGTK.cpp \
	effects/VST/VSTControlGTK.h \
	$(NULL)
endif

To Reproduce
Build Audacity on macOS with autotools.

Additional information (please complete the following information):

• OS: macOS (version not important)
• Version: master branch as of November 19

@RJVB @Paul-Licameli

[RJVB]

On Saturday November 09 2019 15:41:25 Mojca Miklavec wrote: Even if the CMake support gets added, the problem will not simply disappear as CMake would call the compiler based on file ending as well.

It will however be easier with CMake to add file-specific compiler arguments.

A slightly related problem is the following piece of code blindly assuming that everyone using VST must be using GTK. We work around it by replacing `VSTControlGTK.cpp` with `VSTControlOSX.mm`, but this needs some conditional on WXMAC as well.

Conditionals are easy with CMake too. A related, future problem which could be taken into account: wxQt is being rebooted and starting to get somewhere, esp. on MS Windows from what I can see. It definitely has the advantage of hiding a lot more platform-specific issues. At the moment Audacity doesn't support this wx variant at all but it would probably be a good idea to keep its existence in mind when overhauling code that juggles different wx variants (and the build system).

[Paul-Licameli]

It would be most pleasing to segregate all mac-specific Objective-C++ into .mm files not included in the Windows and Linux builds. It would be a pleasing separation. I won't have time to consider the details of that until later this week. PRL On Sun, Nov 10, 2019 at 4:13 AM René Bertin <notifications@github.com> wrote:

…

On Saturday November 09 2019 15:41:25 Mojca Miklavec wrote: >Even if the CMake support gets added, the problem will not simply disappear as CMake would call the compiler based on file ending as well. It will however be easier with CMake to add file-specific compiler arguments. >A slightly related problem is the following piece of code blindly assuming that everyone using VST must be using GTK. We work around it by replacing `VSTControlGTK.cpp` with `VSTControlOSX.mm`, but this needs some conditional on WXMAC as well. Conditionals are easy with CMake too. A related, future problem which could be taken into account: wxQt is being rebooted and starting to get somewhere, esp. on MS Windows from what I can see. It definitely has the advantage of hiding a lot more platform-specific issues. At the moment Audacity doesn't support this wx variant at all but it would probably be a good idea to keep its existence in mind when overhauling code that juggles different wx variants (and the build system). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#387?email_source=notifications&email_token=ACZBGYPEJLPSGJZBCPAB3FTQS7GDTA5CNFSM4JLKCSS2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDUYZ5A#issuecomment-552176884>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACZBGYNRYLFBTFXUO65R5HDQS7GDTANCNFSM4JLKCSSQ> .

[RJVB]

On Sunday November 10 2019 03:14:38 Paul Licameli wrote: .mm files not included in the Windows and Linux builds. It would be a pleasing separation.

The way we'd do that in KDE is by copying (instead of renaming) the required .cpp files to .mm, strip the ObjC code from the old .cpp files, and rewrite the build formula to include the .mm files on Mac instead of the .cpp files. Mostly trivial with CMake ....

[Paul-Licameli]

On Sun, Nov 10, 2019 at 7:19 AM René Bertin <notifications@github.com> wrote:

On Sunday November 10 2019 03:14:38 Paul Licameli wrote: >.mm files not included in the Windows and Linux builds. It would be a >pleasing separation. The way we'd do that in KDE is by copying (instead of renaming) the required .cpp files to .mm, strip the ObjC code from the old .cpp files, and rewrite the build formula to include the .mm files on Mac instead of the .cpp files. Mostly trivial with CMake ....

I hope that does not mean duplication of the C++ needed in both builds. Do you mean the .mm file could #include the common code remaining in the .cpp file? PRL

…

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#387?email_source=notifications&email_token=ACZBGYJJI3Z3K4LZAK3LXETQS7353A5CNFSM4JLKCSS2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDU35FA#issuecomment-552189588>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACZBGYPNQPHXPU4VXSOMMX3QS7353ANCNFSM4JLKCSSQ> .

[RJVB]

I hope that does not mean duplication of the C++ needed in both builds. Do you mean the .mm file could #include the common code remaining in the .cpp file?

Yes. You can of course also put only the ObjC++ code in .mm files which you pull in in addition to the .cpp files. Maybe a bit more work initially but indeed easier to maintain afterwards if only a small proportion is ObjC++ code .

[eszlari]

cmake 3.16 will have support for Objective C/C++:

https://cmake.org/cmake/help/v3.16/release/3.16.html

[mojca]

I know, but that doesn't help in any way at the moment. If files have wrong extension and you don't provide any explicit hints to it, CMake will also not magically recognise the need for objective C. Most importantly though the CMake build system is not yet ready.

[RJVB]

cmake 3.16 will have support for Objective C/C++: https://cmake.org/cmake/help/v3.16/release/3.16.html > CMake learned to support the Objective C (OBJC) and Objective C++ (OBJCXX) > languages. They may be enabled via the project() and enable_language() > commands. When OBJC or OBJCXX is enabled, source files with the .m or .mm, > respectively, will be compiled as Objective C or C++. Otherwise they will > be treated as plain C++ sources as they were before.

I've been using ObjC/ObjC++ with cmake for quite a while now, I wasn't aware this didn't work?! Or maybe it just worked because at the very least clang looks at the file extension (I cannot recall having tried to build ObjC++ enabled projects with GCC).

[JamesCrook]

CMake is now used to build Audacity, so this issue closed. Thanks to all who contributed to it.