include files for cgxCADTools

Mark Brethen mark.brethen at gmail.com
Tue Aug 2 20:51:42 UTC 2022 

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.brethen at gmail.com



> On Aug 2, 2022, at 2:52 PM, Robert Kennedy <amtor at 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 <amtor at hotmail.com>
> Sent: August 2, 2022 3:46 PM
> To: Mark Brethen <mark.brethen at 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 <amtor at hotmail.com>
> Sent: August 2, 2022 3:03 PM
> To: Mark Brethen <mark.brethen at 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 <amtor at hotmail.com>
> Sent: August 2, 2022 3:00 PM
> To: Mark Brethen <mark.brethen at 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.brethen at gmail.com>
> Sent: August 2, 2022 1:34 PM
> To: Robert Kennedy <amtor at 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 <amtor at hotmail.com <mailto:amtor at 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-bounces at lists.macports.org <mailto:macports-dev-bounces at lists.macports.org>> on behalf of Robert Kennedy <amtor at hotmail.com <mailto:amtor at hotmail.com>>
>> Sent: August 2, 2022 8:10 AM
>> To: Mark Brethen <mark.brethen at gmail.com <mailto:mark.brethen at gmail.com>>; MacPorts Developers <macports-dev at lists.macports.org <mailto:macports-dev at 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-bounces at lists.macports.org <mailto:macports-dev-bounces at lists.macports.org>> on behalf of Mark Brethen <mark.brethen at gmail.com <mailto:mark.brethen at gmail.com>>
>> Sent: August 1, 2022 8:51 PM
>> To: MacPorts Developers <macports-dev at lists.macports.org <mailto:macports-dev at 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 <jmr at macports.org <mailto:jmr at 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.brethen at gmail.com <mailto:mark.brethen at 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
>> >>> 
>> >>> 
>> >>> 
>> >

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20220802/c817a784/attachment-0001.htm>

More information about the macports-dev mailing list