Github messages for voidlinux
 help / color / mirror / Atom feed
From: meator <meator@users.noreply.github.com>
To: ml@inbox.vuxu.org
Subject: Re: [PR REVIEW] cmt: update to 1.18 and make it buildable
Date: Tue, 10 Jan 2023 16:00:05 +0100	[thread overview]
Message-ID: <20230110150005.yeERsBqTEh3V7NtTy6NbWAOMVkYKQEaX4CWCy1q-zXY@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-39583@inbox.vuxu.org>

[-- Attachment #1: Type: text/plain, Size: 2237 bytes --]

New review comment by meator on void-packages repository

https://github.com/void-linux/void-packages/pull/39583#discussion_r1065890177

Comment:
> cmt's makefile defines CFLAGS and CXXFLAGS with `=` which completely overrides external variables as far as I can tell.

When `$make_use_env` is unset, xbps-src [very explicitly](https://github.com/void-linux/void-packages/blob/master/common/build-style/gnu-makefile.sh#L7-L13) overrides all relevant variables set in the makefile. It doesn't matter what cmt's makefile wants to do, xbps-src will set it (unless it would be using the `override` keyword or other shenanigans but no one does that for `CFLAGS`).

But as I said it would still omit `-fPIC` which is undesirable.

> Using sed to stuff it with void's flags just because `-fPIC` is present there looks overcomplicated and unnecessary.
> 
> In this case I can suggest the following (I forgot `vsed` must be used instead of `sed`):

I agree that it looks overcomplicated. I think using sed in general isn't really fit for this situation. I'll make an actual patch that fixes this.

While I'm at it I'll try to contact upstream about this.

> > `-fPIC` could be added to `make_build_args`
> 
> Based on my previous answer (I have had overlooked this flag for reasons unknown), I believe it should be left in the makefile since the fix above allows to use void's flags with those in the makefile together without that ugly hack.

This is the best solution. Template files shouldn't be responsible for this.

I have experience with writing makefiles. The absolute best solution is https://www.gnu.org/software/make/manual/make.html#Command-Variables or (my favorite) presume that `CFLAGS` and similar variables are user input and put mandatory flags right into the rule from the beginning like this:
```makefile
a.o : a.c b.c
	$(CC) -c -fPIC --you-can't-override-me-when-I'm-hardcoded=true $(CFLAGS) $(CPPFLAGS) a.c b.c -o a.o
```
but it isn't xbps-src's responsibility to fix build system of other programs and both of these changes would require large patches so I'll make something simpler (probably just change `=` to `+=` but I'm not sure yet). I will propose one of the "correct" solutions to upstream.

  parent reply	other threads:[~2023-01-10 15:00 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-01 13:27 [PR PATCH] " meator
2022-12-31  1:55 ` github-actions
2023-01-02  7:15 ` [PR REVIEW] " kruceter
2023-01-02  7:15 ` kruceter
2023-01-02  7:15 ` kruceter
2023-01-03 13:08 ` [PR PATCH] [Updated] " meator
2023-01-03 13:09 ` meator
2023-01-03 13:19 ` [PR REVIEW] " meator
2023-01-03 13:20 ` meator
2023-01-03 13:21 ` meator
2023-01-07 21:49 ` kruceter
2023-01-07 22:18 ` kruceter
2023-01-10 15:00 ` meator [this message]
2023-01-10 15:23 ` kruceter
2023-04-11  1:51 ` github-actions
2023-04-25  1:53 ` [PR PATCH] [Closed]: " github-actions

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230110150005.yeERsBqTEh3V7NtTy6NbWAOMVkYKQEaX4CWCy1q-zXY@z \
    --to=meator@users.noreply.github.com \
    --cc=ml@inbox.vuxu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).