Re: Issues with config.h

Thanks Ryan. I am torn whether to keep WORDS_BIGENDIAN in the code. Perhaps, I will just leave it in the code and see if anyone reports bugs. This code was compiled my Metakine into a ppc/x86 FAT binary and run without issues for many years. So I suspect the WORDS_BIGENDIAN macro was never

Re: SPOOLES MT routines

On Aug 5, 2022, at 17:45, Mark Brethen wrote: > Note that the pre-build approach is overriding the makefile cflags, makefile > was patched to cflags += , etc. How do I prevent this? Setting variables like CFLAGS as arguments (e.g. build.args) overrides anything specified in the Makefile.

Re: Help with New Port - M2VDownsizer

On Aug 5, 2022, at 18:14, Robert Kennedy wrote: > I have been playing around with CFLAGS += -Xarch_ppc -faltivec in my > Makefile, as suggested by Josh. > > I noticed that if I include CFLAGS += -Xarch_ppc -faltivec in my Makefile, > the output from the clang compiler gets garbled but the

Re: Issues with config.h

On Aug 5, 2022, at 16:43, Robert Kennedy wrote: > > I have also patched config.h to address the ARCH issue. It now reads: > > #ifndef LINUX >   #if defined(__ppc__) || defined(__ppc64__) > #define ARCH_PPC >   #elif defined(__i386__) > #define

Re: Help with New Port - M2VDownsizer

I have been playing around with CFLAGS += -Xarch_ppc -faltivec in my Makefile, as suggested by Josh. I noticed that if I include CFLAGS += -Xarch_ppc -faltivec in my Makefile, the output from the clang compiler gets garbled but the M2VDownsizer binary appears to build fine. E,g,

Re: SPOOLES MT routines

So, moving from a post-patch CFLAGS, etc to a pre-build build.args CalculiX now does not build. So I compared them.Post-Patch::info:build Executing:  cd "/opt/local/var/macports/build/_Users_marbre_ports_cad_CalculiX-ccx/CalculiX-ccx/work/ccx_2.18/src" && /usr/bin/make -j1 -w :debug:build system:  

Re: Issues with config.h

Ryan, Many thanks for the great feedback on my Portfile for M2VDownsizer. That is exactly what I was looking for! My portfile already had PortGroup makefile 1.0 so there was no need to add it. But since there was no details on the PortGroup in the Macports Guide, I looked at the

Re: Issues with config.h

Ryan, I have created a patch file to add include guards everywhere in config.h. see attached. I know it is overkill. But it will address the issue. I also fixed the inline macro which was wrong. #define inline __attribute__ ((__always_inline__)) should really be: #define inline inline

Re: Code signing

On 2022-8-6 06:04 , Christopher Nielsen wrote: And some recent discussion took place via this thread: https://lists.macports.org/pipermail/macports-dev/2022-July/044424.html And this one:

Re: Issues with config.h

Early in config.h it says: #ifndef LINUX #if defined(__ppc__) || defined(__ppc64__) #define ARCH_PPC #elif defined(__i386__) #define ARCH_X86 #endif #else #define ARCH_X86 #endif So, on non-Linux systems, it sets ARCH_PPC when building

Re: include files for cgxCADTools

On Aug 5, 2022, at 15:26, Mark Brethen wrote: > > I don’t see these errors when building with macports-clang, only Apple’s > clang. Ok. Certainly, different compilers can behave differently. I didn't try to see what the actual error was, since it was jumbled. If you have an non-jumbled error

Re: Issues with config.h

On Aug 4, 2022, at 08:36, Robert Kennedy wrote: > e.g. > ./config.h:29:9: warning: 'HAVE_STDINT_H' macro redefined > #define HAVE_STDINT_H > ^ > ./config.h:42:9: note: previous definition is here > #define HAVE_STDINT_H 1 The config.h file clearly does define HAVE_STDINT_H (empty)

Re: include files for cgxCADTools

I don’t see these errors when building with macports-clang, only Apple’s clang. Mark Brethen mark.bret...@gmail.com > On Aug 5, 2022, at 3:09 PM, Ryan Schmidt wrote: > > On Aug 4, 2022, at 13:19, Mark Brethen wrote: > >> I’m seeing this error when generate all the header dependencies for

Re: include files for cgxCADTools

On Aug 4, 2022, at 13:19, Mark Brethen wrote: > I’m seeing this error when generate all the header dependencies for > FbdReader. This is confusing, which file has the error? Error messages from several different files are being jumbled together due to parallel building. You can make it less

RE: Code signing

> I’m using a couple of ports that deliver services (unbound/nsd, dovecot, > postfix, nginx, minIO, etc.) and the reliability of these being able to be > started and used becomes less and less over the successive macOS versions. I > have no proof, but I get the distinct feeling that unsigned

Re: SPOOLES MT routines

On Aug 5, 2022, at 14:32, Mark Brethen wrote: > > pre-build { > set cflags "${configure.cflags} [get_canonical_archflags cc]" > set ldflags "${configure.ldflags} [get_canonical_archflags ld]" > > # workaround for Rank mismatch between actual argument > set ver [regsub -all

Re: SPOOLES MT routines

Need to build spooles library before CalculiX-ccx: pre-build { set cflags "${configure.cflags} [get_canonical_archflags cc]" set ldflags "${configure.ldflags} [get_canonical_archflags ld]" # workaround for Rank mismatch between actual argument set ver [regsub -all

Re: port notes

You can get the same result using a single quoted string containing literal newlines: notes \ "- To test for a successfull installation, execute the tool by typing \"cad2fbd\" -> some usage information should be displayed - The file result.fbd should be opened with the cgx parameter '-a'

Re: port notes

With a little experimentation I got it: notes \ "- To test for a successfull installation, execute the tool by typing \"cad2fbd\"" \ \n \ "-> some usage information should be displayed" \ \n \ "- The file result.fbd should be opened with the cgx

Re: port notes

On 2022-8-6 02:30 , Mark Brethen wrote: Is formatting (e.g. \n for newline) available in the notes section of a portfile? Or is it just one block of text. This is pretty easy to test, no? Yes, it's an arbitrary string, newlines are fine. Easiest to include them if you enclose the string in

port notes

Is formatting (e.g. \n for newline) available in the notes section of a portfile? Or is it just one block of text. Mark Brethen mark.bret...@gmail.com