Skip to content

Conversation

@trustbyte
Copy link
Contributor

Description

Type(s)
  • bugfix
  • enhancement
  • security fix
Tested on

macOS 26.1 25B78 arm64
Xcode 26.1.1 17B100

Verification

Have you

  • followed our Commit Message Guidelines?
  • squashed and minimized your commits?
  • checked that there aren't other open pull requests for the same change?
  • referenced existing tickets on Trac with full URL in commit message?
  • checked your Portfile with port lint?
  • tried existing tests with sudo port test?
  • tried a full install with sudo port -vst install?
  • tested basic functionality of all binary files?
  • checked that the Portfile's most important variants haven't been broken?

@macportsbot
Copy link

Notifying maintainers:
@paul-j-lucas for port cdecl.

@trustbyte
Copy link
Contributor Author

Checks fail because: fb3abc7#r172700524

@paul-j-lucas
Copy link

Notifying maintainers: @paul-j-lucas for port cdecl.

Perhaps I missed it, but the error(s) seem like they have only to do with macports stuff, not cdecl sources itself.

If the issue is with cdecl itself, could somebody point me to the specific issue with cdecl?

@trustbyte
Copy link
Contributor Author

Yes @paul-j-lucas, the issue
is with the Macports runners not the package itself.

If you are wondering why not the latest 18.6 is because that one fails with some parser.h error that I simply did not want to patch or whatever was need it.

@paul-j-lucas
Copy link

Well, if the issue isn't with cdecl itself, them I'm not sure why I was tagged.

As for cdecl 18.6, if you can send me the error output, I can fix it upstream.

@trustbyte
Copy link
Contributor Author

You were tagged so you can approve this update.

About the 18.6 attached the entire debug build for it (same Portfile just the version and checksum changed).
debug_build_18_6.txt

ake[1]: Entering directory `/opt/local/var/macports/build/cdecl-81741c6b/work/cdecl-18.6/src'
/bin/sh ../ylwrap parser.y y.tab.c parser.c y.tab.h `echo parser.c | sed -e s/cc$/hh/ -e s/cpp$/hpp/ -e s/cxx$/hxx/ -e s/c++$/h++/ -e s/c$/h/` y.output parser.output -- bison -y -d -Wno-yacc 
/bin/sh ../ylwrap lexer.l .c lexer.c --   
../ylwrap: line 173: : command not found
make[1]: *** [lexer.c] Error 127
make[1]: *** Waiting for unfinished jobs....
updating parser.h
make[1]: Leaving directory `/opt/local/var/macports/build/cdecl-81741c6b/work/cdecl-18.6/src'
make: *** [all-recursive] Error 1

@paul-j-lucas
Copy link

You were tagged so you can approve this update.

This update only updates a Portfile. I don't know anything about Portfiles, so I can't make an informed decision as to whether this update should be approved or not. (I've never been asked before about approving a change to a Portfile.)

As for the : command not found, that's some weird Autotools caching bug that I thought I fixed a while ago — see SHA 62f90902. I never understood why it happens sometimes. It only ever occasionally happens on rebuilds. If you start from a clean slate, e.g., after a git clean -dfx, it should go away (or it always has in the past).

@trustbyte
Copy link
Contributor Author

Well you are asked now :) and if you read a few minutes most likely you could Portfiles more than I.
Like for example those two libaries, ncurses and readline are they need it at runtime? Did I miss some other library?

As for your indication I do not know how to do that git clean -dfx in the build process and as such the error is persistent and is reproducible every time i do sudo port -dv test with that latest version. Let us try again when this package is updated to 18.7 or greater and see if the error persists.

@paul-j-lucas
Copy link

  • ncurses is needed iff --disable-term-size is not given (i.e., by default).
  • readline is needed iff --without-readline is not given (i.e., by default).

Are they needed at runtime? It depends if you link statically or dynamically. (That's universally true for any package and any libraries.)

@trustbyte
Copy link
Contributor Author

Thanks, nothing more with this I guess.

@paul-j-lucas
Copy link

As for your indication I do not know how to do that git clean -dfx in the build process ...

The other alternative is always to untar into a fresh directory.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Development

Successfully merging this pull request may close these issues.

3 participants