I stripped those lines but there were some glitches in the build. First the Makefile only defines CC but the source is c++.
:info:build /opt/local/include/opencascade/Standard_Handle.hxx:75:19: warning: rvalue references are a C++11 extension [-Wc++11-extensions] Second, I’m missing an include somewhere. :info:build plotTopology() in CadReader.o :info:build std::__1::basic_stringstream<char, std::__1::char_traits<char>, std::__1::allocator<char> >::~basic_stringstream() in CadReader.o :info:build ... :info:build ld: symbol(s) not found for architecture x86_64 :info:build clang: error: linker command failed with exit code 1 (use -v to see invocation) :info:build make: *** [tmain] Error 1 https://pastebin.com/9xYCd74R <https://pastebin.com/9xYCd74R> Mark Brethen [email protected] > On Aug 2, 2022, at 12:34 PM, Mark Brethen <[email protected]> wrote: > > Rob, > > There is the line '.PHONY: depend clean' but 'make all’ only calls $(MAIN). > <Makefile> > <patch-CadReader-build.diff> > > Thanks, > Mark > > > >> On Aug 2, 2022, at 9:34 AM, Robert Kennedy <[email protected] >> <mailto:[email protected]>> wrote: >> >> Mark, >> >> To be clear, I would first try patching the Makefile by deleting all the >> system header dependencies from the Makefile and then see if Macports will >> build the project. But make sure the Makefile lists the location of all the >> directories where the header files are located. (I typically place them in >> $(INCLUDES)). And make sure the rules contain $(INCLUDES). >> >> You typically do not need to list the directories of the system header files >> because the compiler typically knows where they are (which as you know may >> change from MacOS to MacOS). >> >> If you want to know why, keep reading.... >> >> Typically "make" only needs to know the following to build the initial >> Project from scratch: >> The rules that define what source code files are needed to build each >> object and a rule for linking the object files and the location of the >> directories for the header files (e.g. main.h). >> e.g >> >> INCLUDES := -I./ >> >> .PHONY all >> >> all: edit >> >> edit: main.o kdb.o >> $(CC) $(LDFLAGS) -o main.o kbd.o >> >> main.o: main.c myfunc.c >> $(CC) $(CFLAGS) $(INCLUDES) -c main.c myfunc.c >> >> kbd.o: kbd.c >> $(CC) $(CFLAGS) $(INCLUDES) -c kbd.c >> >> >> In the example above, the directories of the header files are in listed in >> $(INCLUDES). >> >> You do not need to list the directories of the system header files in >> $(INCLUDES) because the compiler knows where they are (which as you know may >> change from MacOS to MacOS). >> >> Ideally, if you know that a particular header is a dependency for an object, >> it is better to list it in the rule (e.g. main.o: main.c myfunc.c main.h) >> OR create a separate rule for the header dependency: >> >> main.o: main.h >> >> But these header dependency rules are typically not needed to build the >> initial project from scratch! These rules exist so "make" will only rebuild >> the minimum number of objects when a header file has changed. >> >> E.g. If I change header.h and then run "make all" again in the above >> example, make will only recompile main.o and then it will link main.o with >> the previously built kbd.o. kbd.o does not need to be recompiled. This >> saves time. Great for development! >> >> Macports does not do this. It typically will rebuild the whole project from >> scratch. (i.e. build all the objects and then link them into the final >> product). >> >> In my view, Macports was not designed for development but for building a >> finished project and making a binary package. (i.e. package management) >> >> If you are still having problems, please EMAIL me the Makefile and I will >> take a look. >> >> RobK88 >> From: macports-dev <[email protected] >> <mailto:[email protected]>> on behalf of Robert >> Kennedy <[email protected] <mailto:[email protected]>> >> Sent: August 2, 2022 8:10 AM >> To: Mark Brethen <[email protected] <mailto:[email protected]>>; >> MacPorts Developers <[email protected] >> <mailto:[email protected]>> >> Subject: Re: include files for cgxCADTools >> >> Mark, >> >> I agree with Josh, these headers look like they were automatically generated >> using something like "make depends". >> >> When creating a Makefile, it is GOOD practice to include these lines as it >> will ensure that the Project will rebuild the correct files when a header >> file was changed. Since it is a REAL pain to create them manually. Many >> developers use something like "make depends". >> >> If there is a "depends:" target in the Makefile, you could patch the >> Makefile and add "depends" as the first Phony target to the "all:" target. >> e.g. >> >> all: depends main etc etc >> >> Alternatively, you could try just patching the Makefile by removing all >> these lines (and any other line where a system header is the ONLY dependency >> in the rule). The vast majority of time, they are NOT needed to build the >> initial project. (They are needed if you want to use "make" to rebuild your >> project properly on subsequent runs where the developer has changed one of >> more of these system header files. This is not a normal scenario if one is >> using Macports to build the project). >> >> The most important rules are the rules involving the source code files >> (which must be kept). >> e.g. $(OBJDIR-MAIN)/%.o: %.c >> $(CC) $(CFLAGS) $(INCLUDES) -c $< -o $@ >> >> Make sure the Makfile has an "INCLUDES:" that lists the location of all the >> header files. If it does, make will find them and build the initial project! >> >> e.g. I am working on a new port where I converted an Xcode project to one >> using a Makefile. I used "make depends" to generate these dependencies, >> Macports built the code just fine when I either: >> Deleted all the lines below "# DO NOT DELETE THIS LINE -- make depend needs >> it"; or >> Added "depends" as the first phony target to the all: phoney target >> e.g. all: depends utils altivec mpeg2enc main $(PRODUCT) >> >> You could even patch the Makefile and add another target called "macports" >> and tell Macports to build that: >> >> macports: depends all >> >> And in the portfile, you would add: >> >> build.target macports >> >> Good luck, >> >> Rob >> >> >> From: macports-dev <[email protected] >> <mailto:[email protected]>> on behalf of Mark Brethen >> <[email protected] <mailto:[email protected]>> >> Sent: August 1, 2022 8:51 PM >> To: MacPorts Developers <[email protected] >> <mailto:[email protected]>> >> Subject: Re: include files for cgxCADTools >> >> I’ll ask the developer >> >> Sent from my iPhone >> >> > On Aug 1, 2022, at 4:53 PM, Joshua Root <[email protected] >> > <mailto:[email protected]>> wrote: >> > >> > A lot of them aren't even standard headers; I believe the ones under >> > bits/ are glibc implementation details. I would suspect this part of the >> > Makefile was not hand-written but generated with one of the compiler's -M >> > options. To work correctly in that case, it would need to be regenerated >> > for each new system the software is built on. >> > >> > - Josh >> > >> >> On 2022-8-2 05:23 , Chris Jones wrote: >> >> The makefile here is very poorly written. You should never directly >> >> reference standard headers like that… >> >>>> On 1 Aug 2022, at 4:52 pm, Mark Brethen <[email protected] >> >>>> <mailto:[email protected]>> wrote: >> >>> >> >>> This Makefile has the following lines: >> >>> >> >>> CadReader.o: /usr/include/stdlib.h /usr/include/bits/libc-header-start.h >> >>> CadReader.o: /usr/include/features.h /usr/include/stdc-predef.h >> >>> CadReader.o: /usr/include/sys/cdefs.h /usr/include/bits/wordsize.h >> >>> CadReader.o: /usr/include/bits/long-double.h /usr/include/gnu/stubs.h >> >>> CadReader.o: /usr/include/bits/waitflags.h /usr/include/bits/waitstatus.h >> >>> CadReader.o: /usr/include/bits/floatn.h /usr/include/sys/types.h >> >>> CadReader.o: /usr/include/bits/types.h /usr/include/bits/typesizes.h >> >>> CadReader.o: /usr/include/bits/types/clock_t.h >> >>> CadReader.o: /usr/include/bits/types/clockid_t.h >> >>> CadReader.o: /usr/include/bits/types/time_t.h >> >>> CadReader.o: /usr/include/bits/types/timer_t.h >> >>> CadReader.o: /usr/include/bits/stdint-intn.h /usr/include/endian.h >> >>> CadReader.o: /usr/include/bits/endian.h /usr/include/bits/byteswap.h >> >>> CadReader.o: /usr/include/bits/byteswap-16.h >> >>> CadReader.o: /usr/include/bits/uintn-identity.h /usr/include/sys/select.h >> >>> CadReader.o: /usr/include/bits/select.h >> >>> /usr/include/bits/types/sigset_t.h >> >>> CadReader.o: /usr/include/bits/types/__sigset_t.h >> >>> CadReader.o: /usr/include/bits/types/struct_timeval.h >> >>> CadReader.o: /usr/include/bits/types/struct_timespec.h >> >>> CadReader.o: /usr/include/sys/sysmacros.h /usr/include/bits/sysmacros.h >> >>> CadReader.o: /usr/include/bits/pthreadtypes.h >> >>> CadReader.o: /usr/include/bits/thread-shared-types.h >> >>> CadReader.o: /usr/include/bits/pthreadtypes-arch.h /usr/include/alloca.h >> >>> CadReader.o: /usr/include/bits/stdlib-float.h >> >>> >> >>> /usr/include doesn’t exist on Big Sure (I assume its deprecated?) >> >>> however, they can be found at >> >>> >> >>> ~ $ xcrun --sdk macosx --show-sdk-path >> >>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk >> >>> >> >>> although I don’t see a ‘bits’ subdirectory. Has it been relocated? >> >>> >> >>> Thanks, >> >>> Mark >> >>> >> >>> >> >>> >> > >
