Help with a Portfile

[Mojca Miklavec]

Dear Eric,

On Sun, 13 Jan 2019 at 14:32, iEFdev wrote:
>
> there is that other thing - that the commit I used is the last one made, and it's ≈ 2 years newer than last release.

(Intermediate comment: since you are probably not packaging some
proprietary software, it could be easier to explain the issues by
pointing to the concrete sources than trying to explain the situation
:)

This is often a perfectly valid usecase for fetching the source from
git. You just need to make sure that you don't specify master, but
provide the shasum instead. (And you need to live with the fact that
until we merge the code from base, those sources would be re-fetched
each time when you compile your port.)

I would suggest you to post your code somewhere and then it will be
easier to understand what goes wrong.

> But maybe one could take one of the releases, and create an additional patch from the last commit - just to get up to date? I dont' think it's that many commits behind. :)

This is of course also possible, it depends on the individual situation.

> The patch files are inside the downloaded directory as a part of the download, sort of. Thought it would be nice to bee able to use them at their current location, instead of taking the patch and put in a Files directory.

For a strange reason something like that didn't work for me (but it
seems like a relatively trivial glitch in the base code; probably
because most developers did not need something like that before).

> I did play a little with this one:
>
> post-fetch {
>     system -W ${worksrcpath} "patch --input=path/to/patch_file.diff"
> }

This is approxmately what I ended up doing (but I don't like it):

set file_patch msp430-gcc-7.3.2.154-source-patches/binutils-2_26.patch
pre-patch {
    system -W ${worksrcpath} "/usr/bin/patch -p0 < ${workpath}/${file_patch}"
}

> But, then it's outside the system, sort of. Hard to patch it manual with: port patch foobar

I don't understand what you wanted to say here.

> [1] https://github.com/macports/macports-ports/pull/3336
>
> Yes, it was something simular I had in mind.
>
> I thought, with:
> patch.dir ${worksrcpath}/path/to
> patchfiles patch_file.diff

I believe that patch.dir is the directory where you run the patch
command, so where you files that need patching are, not the patches
themselves.

I tried patchfiles ${worksrcpath}/path/to/patch_file.diff (as would be
the case in your example), but that was still checking under
files/${worksrcpath}...

> it would (hopefully) do the same thing as above (w system -W …). :)
> That specifying a patch.dir would make the Files dir unnecessary.

If patches are of non-trivial size, it's in fact better not to put
them in the tree.

I hope someone more knowledgable than me will reply ...

Mojca