I found the issue: There should be header files in
‘${workpath}/cgxCadTools/CadReader/inc’ but for some reason the extract phase
is omitting them, i.e. the ‘inc’ directory is empty.
Why would it be doing this?
Mark Brethen
mark.bret...@gmail.com
> On Aug 2, 2022, at 2:52 PM, Robert Kennedy <am...@hotmail.com> wrote:
>
> I missed one. You also need to change:
>
> $(CC) $(LDFLAGS) $(INCLUDES) -o $(MAIN) $(OBJS) $(LFLAGS) $(LIBS)
>
> to
>
> $(CCX) $(LDFLAGS) $(INCLUDES) -o $(MAIN) $(OBJS) $(LFLAGS) $(LIBS)
>
> Rob
> From: Robert Kennedy <am...@hotmail.com>
> Sent: August 2, 2022 3:46 PM
> To: Mark Brethen <mark.bret...@gmail.com>
> Subject: Re: include files for cgxCADTools
>
> Mark,
>
> Since it is a C++ project (not a C project), I modified the Makefile
> accordingly. See attached.
>
> Please note that I added LDFLAGS = -stdlib=libc++ and added $LDFLAGS to the
> Makefile target that does the linking.
>
> This is needed so the code will link properly on older macs (like my old Mac
> running Lion).
>
> Alternatively, you could add the following to the Portfile:
> configure.ldflags-append "-stdlib=${configure.cxx_stdlib}"
>
> Rob
>
> From: Robert Kennedy <am...@hotmail.com>
> Sent: August 2, 2022 3:03 PM
> To: Mark Brethen <mark.bret...@gmail.com>
> Subject: Re: include files for cgxCADTools
>
> I forgot to mention that I normally change all the CFLAGS and LDFLAGS as
> follows:
>
> CFLAGS = blah blah
> CFLAGS += blah blah
>
> This will allow Macports to add its own flags.
>
> You do not need to do that with CC or CCX.
>
> Rob
> From: Robert Kennedy <am...@hotmail.com>
> Sent: August 2, 2022 3:00 PM
> To: Mark Brethen <mark.bret...@gmail.com>
> Subject: Re: include files for cgxCADTools
>
> Mark,
>
> I could not get the patch file to patch the Makefile. So I manually applied
> the patches. And added my changes.
>
> Attached please find the FINAL Makefile and a patch file showing all the
> diffs (including yours) from the original Makefile.
>
> I also did the following:
> Deleted all the dependencies, generated by makedepend below the "# DO NOT
> DELETE THIS LINE -- make depend needs it" line.
> Added "macports" to .PHONY (P.S. PHONY targets provide rules that do not
> directly build or link real binary objects. They call on other targets that
> build and link the actual code).
> Added the "macports" target:
> macports: depend all
> The rule for the Macports target is:
>
> macports: depend all
>
> When make macports is run, it will first run the "depend" target in the
> Makefile and generate all the header dependencies and then it will run the
> "all" target to build and link the code.
>
> Now you have two choices as far as Macports is concerned:
> Just use the Makefile as is and see if the code builds and links. It likely
> will unless you are missing a header directory in $(INCLUDES). OR
> Add the following to the Portfile which causes makedepend to run (which will
> generate all those dependencies) before compiling and linking the code:
> depends_build port:makedepend
> build.target macports
> If the Makefile is doing all the building and linking for your Project, you
> should probably also add the following to the Portfile:
>
> PortGroup makefile 1.0
>
> I am working with a similar Makefile. Both approaches above work for me.
> Approach 1 runs a lot faster since it does not call on makedependto generate
> all those header dependencies (which can take some time for a large project).
> And as mentioned in my previous posts to the Macports mailing list, the
> compiler typically does NOT need to know about these header dependencies to
> properly build and link the final binary product for the first time.
>
> But the compiler does need to know the location of all the directories where
> all the non-system headers can be found so when it processes an #include in a
> source file, it can find the needed header. The $(INCLUDES) does not need to
> contain any of the directories where the system headers are located since the
> compiler knows where they are. And as you found out, the location of the
> system headers will change from MacOS to MacOS.
>
> I went with Approach 1 for my project.
>
> P.S. It looks like the project is using autotools or cmake to generate the
> Makefile so you likely need to patch the Makefile at the end of the configure
> stage or before building. The most important thing is deleting all those
> header dependencies at the end of the Makefile.
>
> Good Luck.
>
> Rob
>
>
> From: Mark Brethen <mark.bret...@gmail.com>
> Sent: August 2, 2022 1:34 PM
> To: Robert Kennedy <am...@hotmail.com>
> Subject: Re: include files for cgxCADTools
>
> Rob,
>
> There is the line '.PHONY: depend clean' but 'make all’ only calls $(MAIN).
>
> Thanks,
> Mark
>
>
>
>> On Aug 2, 2022, at 9:34 AM, Robert Kennedy <am...@hotmail.com
>> <mailto:am...@hotmail.com>> 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 <macports-dev-boun...@lists.macports.org
>> <mailto:macports-dev-boun...@lists.macports.org>> on behalf of Robert
>> Kennedy <am...@hotmail.com <mailto:am...@hotmail.com>>
>> Sent: August 2, 2022 8:10 AM
>> To: Mark Brethen <mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>>;
>> MacPorts Developers <macports-dev@lists.macports.org
>> <mailto:macports-dev@lists.macports.org>>
>> 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 <macports-dev-boun...@lists.macports.org
>> <mailto:macports-dev-boun...@lists.macports.org>> on behalf of Mark Brethen
>> <mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>>
>> Sent: August 1, 2022 8:51 PM
>> To: MacPorts Developers <macports-dev@lists.macports.org
>> <mailto:macports-dev@lists.macports.org>>
>> 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 <j...@macports.org
>> > <mailto:j...@macports.org>> 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 <mark.bret...@gmail.com
>> >>>> <mailto:mark.bret...@gmail.com>> 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
>> >>>
>> >>>
>> >>>
>> >
