search

phillbush / xmenu

a x11 menu utility
Other
296 stars 26 forks source link

POSIX Makefile #34

Closed astralchan closed 1 year ago

astralchan commented 2 years ago

I figure if the idea is to make this portable, to write it POSIX compatible. install and PATH ?= value are extensions of make(1p). You only have one .c source file - no need to make a double suffix rule for object files. Tested with GNU Make and BSD Make.

phillbush commented 2 years ago

I'd like to have MANPREFIX separated from MANDIR, since in OpenBSD (and other systems), the MANPREFIX is ${PREFIX}/man (and not ${PREFIX}/share/man). Having only MANDIR would require the port maintainer or package maintainer to edit both the path and to remember to include the ${DESTDIR} before it.

The ${...} to $(...) conversion is unnecessary. Both are mandated by POSIX (one is used in BSD makefiles and the other on GNU makefiles, I use the BSD style for habit).

Also, I prefer to not define ${CFLAGS} and ${LDFLAGS}, because a port maker or package maintainer may want to define other options to ${CC} (for example, to specify another include directory or another name for the library), and passing those extra options on ${CFLAGS} and ${LDFLAGS} is the most common way. However, if the Makefile writer populates those variables, the package maintainer would have to resort to another method. If we were using GNU/BSD makefiles, we could use += to append the hardcoded values for those variables with the values specified by the package mantainer, but now that you are proposing full POSIX portability (and there is no +=), appending is no more an option.

But, in the end, I don't know whether I want to achieve full POSIX portability... If xmenu was to be fully portable, I'd have to edit not only its Makefile but also its code: It uses BSD/GNU extensions, such as the functions in the <err.h> header. If we go full POSIX I'd have to implement my own err-like functions...

astralchan commented 2 years ago

I'd like to have MANPREFIX separated from MANDIR, since in OpenBSD (and other systems), the MANPREFIX is ${PREFIX}/man (and not ${PREFIX}/share/man). Having only MANDIR would require the port maintainer or package maintainer to edit both the path and to remember to include the ${DESTDIR} before it.

The ${...} to $(...) conversion is unnecessary. Both are mandated by POSIX (one is used in BSD makefiles and the other on GNU makefiles, I use the BSD style for habit).

Also, I prefer to not define ${CFLAGS} and ${LDFLAGS}, because a port maker or package maintainer may want to define other options to ${CC} (for example, to specify another include directory or another name for the library), and passing those extra options on ${CFLAGS} and ${LDFLAGS} is the most common way. However, if the Makefile writer populates those variables, the package maintainer would have to resort to another method. If we were using GNU/BSD makefiles, we could use += to append the hardcoded values for those variables with the values specified by the package mantainer, but now that you are proposing full POSIX portability (and there is no +=), appending is no more an option.

But, in the end, I don't know whether I want to achieve full POSIX portability... If xmenu was to be fully portable, I'd have to edit not only its Makefile but also its code: It uses BSD/GNU extensions, such as the functions in the <err.h> header. If we go full POSIX I'd have to implement my own err-like functions...

Any objection to using pkg-config?

phillbush commented 2 years ago

Any objection to using pkg-config?

I do not want to use it, some BSD systems do not have it installed by default. And xmenu is already on the ports system of those BSDs, using pkg-config would require the ports maintainers to rewrite it.

astralchan commented 2 years ago

Okay, when I get back home I'll update PR with ammended commit.