On Jan 16, 2019, at 14:03, Eric F (iEFdev) wrote:

> On 1/16/19 19:22 , Ryan Schmidt wrote:
>> On Jan 15, 2019, at 15:55, Eric F (iEFdev) wrote:
>> 
>>> It's a 2 part install. C lib (dependency) + a module.
>>>     - 
>>> https://github.com/maxmind/libmaxminddb/
>> I tried to build this Portfile and found that in the libtap directory, the 
>> build system is not using the compiler nor flags that MacPorts specified. 
>> This can be fixed with the usual dance:
>> 
>> variant universal {}
>> build.env-append    CC="${configure.cc}" \
>>                     CFLAGS="${configure.cflags} [get_canonical_archflags 
>> cc]" \
>>                     LDFLAGS="${configure.ldflags} [get_canonical_archflags 
>> ld]"
>> 
>> Then it builds fine for me. If you're ready, I'll commit this one for you.
>> 
>> I've made a few minor changes: Removed the name line, since github.setup 
>> sets it for you; changed the homepage to the one indicated on the GitHub 
>> project; and fixed the maintainer line: would you like to maintain the port? 
>> If so, I'll list your obfuscated email and "openmaintainer", otherwise 
>> "nomaintainer".
>> 
>> I've attached my revised Portfile to this ticket: 
>> https://trac.macports.org/ticket/44709
> Thanks Ryan! I'll look in to this right away.
> 
> I did push the Portfile to a tmp branch on my MP fork: 
> https://github.com/iEFdev/macports-ports/blob/maxminddb_x2/devel/libmaxminddb/Portfile

Ok, if you'd like to make further changes in your branch and submit a PR, 
that's fine. Or if you'd like to attach updated Portfiles to the Trac tickets 
that's fine too.


> For the maintainer… The old 'libgeoip' was pixilla. I sent him an email 
> asking if he wanted this one as well, but haven't heard anything. I guess 
> nomaintainer is better, unless I should be in there. It's ok.

pixilla hasn't been seen in awhile. We're planning to remove him as maintainer:

https://trac.macports.org/ticket/57827

If you want to maintain the port (submit updates; have tickets about the port 
assigned to you) then list yourself, otherwise don't.


>> The destroot then fails because apxs is trying to install directly into 
>> prefix, bypassing destroot. I don't know how to fix that. If apxs can be 
>> told about DESTDIR that would be great, otherwise we could bypass apxs and 
>> just copy the file to the right place ourselves.
>> 
>> I've attached my modified Portfile to this new ticket: 
>> https://trac.macports.org/ticket/57919
> Ok, that might explain why I needed to use destroot {} (in mod_*), instead of 
> post-destroot {} (lib*) then?

If you can do everything that needs to be done for the destroot phase in Tcl 
code in the Portfile, then yes, you could override the destroot phase entirely 
using a destroot block.


> With this patch… There's no need for the other fix (build.env-append*), or 
> should that one go in this file to?
> 
> // * as in:
>> variant universal {}
>> build.env-append    CC="${configure.cc}" \
>>                     CFLAGS="${configure.cflags} [get_canonical_archflags 
>> cc]" \
>>                     LDFLAGS="${configure.ldflags} [get_canonical_archflags 
>> ld]"

Correct. I only added that to fix a bug in libmaxminddb's build system. 
mod_maxminddb doesn't have that same issue.


> Do we continue here, or in the trac ticket(s)?

If you have further questions about how to do something in a Portfile, asking 
on the mailing list is fine. If you have updated versions of Portfiles or 
patches, attaching them to the ticket is good, or put them in your branch and 
send a link to that.


>> … since github.setup sets it for you;
> An off-topic question about github.setup… There's no gitlab.setup?
> Or can it be used by manually specifying some variables? Their API's are 
> almost identical.
> Haven't seen any port using Gitlab, but it would be great if one could.

I don't think anybody has worked on a gitlab portgroup. I'm sure there are 
several ports already for software that's hosted at gitlab. Having such a 
portgroup is probably a good idea.


Reply via email to