Re: Build Failure: gstreamer1-gst-plugins-bad, mesa, x265
On 11/28/16 3:31 PM, Ryan Schmidt wrote:
>
> On Nov 27, 2016, at 7:49 PM, David Evans wrote:
>
>> On 11/27/16 5:10 PM, Jeremy Huddleston Sequoia wrote:
>>> From:
>>>
>>> https://build.macports.org/builders/ports-10.6_x86_64_legacy-builder/builds/11628/steps/install-port/logs/stdio
>>>
>>> DEBUG: Using compiler 'System cc'
>>>
>>> Why is that the case?
>>>
>>> Is xcodeversion not getting set right such that
>>> portconfigure::get_compiler_fallback is doing:
>>>
>>> # Check for platforms without Xcode
>>> if {$xcodeversion eq "none" || $xcodeversion eq ""} {
>>> return {cc}
>>> }
>>>
>>> --Jeremy
>>
>> I'm seeing alot of these errors on this buildbot as well and this build is
>> no exception
>>
>> Warning: xcodebuild exists but failed to execute
>>
>> Perhaps CLI tools are not properly installed?
>
>
> A recurrence of this problem, I guess:
>
> https://trac.macports.org/ticket/52543
>
> Suggestions welcome. Something about Xcode / command line tools / xcodebuild
> seems to corrupt itself on Snow Leopard after running for awhile. I don't
> know if I should just reboot the VM again or try to reinstall Xcode and the
> command line tools this time.
>
> .
>
Similar problem with libvpx. Should be building with clang-3.4 rather than
/usr/bin/cc.
https://build.macports.org/builders/ports-10.6_x86_64_legacy-watcher/builds/3256
Re: `git describe`
On 29 November 2016 at 19:42, René J.V. Bertin wrote: > On Tuesday November 29 2016 19:03:04 Clemens Lang wrote: > >> By asking. Somebody who wastes developers time by hiding the fact that >> they are running and older version on purpose will end up no longer >> getting support at some point. > > Well, regardless of whether the reporter is hiding things on purpose, you'll > still have to ask for technical details in order to be certain that the > installed version is indeed too old. > > If you prefer to do that rather than having the info available in the log, > who am I to suggest otherwise :) This reminded me of https://trac.macports.org/ticket/52575 It would probably be helpful to print MacPorts version to main.log as well. Mojca
Re: How to ignore the “Scanning binaries for linking errors“ for cross platform toolchains
On 2016-11-30 00:03 , Martin Krischik wrote: Hello Joshue, Joshua Root schrieb: On 2016-11-24 05:28 , Martin Krischik wrote: Hello Just wanted to bring the android port up to date when noticed the the “Scanning binaries for linking errors” has been upgraded from warning to error. That is a bit of a problem as the android port is toolchain for cross platform development and as such contains several libraries for other platforms. Those libraries will, of course, always fail the link test. Any ideas what can be done? For rev-upgrade to try to do anything about these libraries they would have to be (a) Mach-O and (b) an architecture that the host machine can run. Is that really the case for the Android SDK? I finally managed to get useful error message. Had to set «revupgrade_mode report». And the three files reported are from the emulator: DEBUG: Marking /opt/local/share/java/android-sdk-macosx/tools/qemu/darwin-x86_64/qemu-system-mips64el as broken DEBUG: Marking /opt/local/share/java/android-sdk-macosx/tools/qemu/darwin-x86_64/qemu-system-x86_64 as broken ---> Found 3 broken file(s), matching files to ports ---> Found 1 broken port(s): android @24.4.1 /opt/local/share/java/android-sdk-macosx/tools/qemu/darwin-x86_64/qemu-system-aarch64 /opt/local/share/java/android-sdk-macosx/tools/qemu/darwin-x86_64/qemu-system-mips64el /opt/local/share/java/android-sdk-macosx/tools/qemu/darwin-x86_64/qemu-system-x86_64 From the “x86_64” inside the directory name one might think them to be of the correct architecture while the mips64el from the filename does not sound as promising. OK, so they're shipping a copy of qemu. I assume it would be for running on the host to test your android programs; mips64el etc. would be the arch being emulated. How are these binaries linked? Can you run them? - Josh
Re: `git describe`
On Tuesday November 29 2016 19:03:04 Clemens Lang wrote: Since you decided to answer despite the smiley ... :) > By asking. Somebody who wastes developers time by hiding the fact that > they are running and older version on purpose will end up no longer > getting support at some point. > > No need to solve a social problem with technical measures. Well, regardless of whether the reporter is hiding things on purpose, you'll still have to ask for technical details in order to be certain that the installed version is indeed too old. If you prefer to do that rather than having the info available in the log, who am I to suggest otherwise :) R
Re: `git describe`
Hi, On Tue, Nov 29, 2016 at 05:17:18PM +0100, René J.V. Bertin wrote: > With the risk of trolling: how do you determine whether someone is > running an older version? ;) By asking. Somebody who wastes developers time by hiding the fact that they are running and older version on purpose will end up no longer getting support at some point. No need to solve a social problem with technical measures. -- Clemens
Re: [macports/macports-ports] cmake-1.[01].tcl: Ensure that cmake based ports use the correct compiler (#66)
On Tuesday November 29 2016 13:21:17 René J.V. Bertin wrote:
Sorry for the noise, I misread and evidently didn't do a copy/paste;
> sh: -DCMAKE_C_COMPILER=${configure.cc}: bad substitution
Jeremy uses $CC from the environment, not the `configure.cc` options.
This does mean that one cannot verify the definitive configure command before
running it but so be it.
R.
Re: `git describe`
On Tuesday November 29 2016 16:53:26 Clemens Lang wrote: >reasonably often, since the first answer you'll get when filing a bug against >an >older version of master is 'update to the latest version'. With the risk of trolling: how do you determine whether someone is running an older version? ;) R.
Re: `git describe`
Hi, - On 29 Nov, 2016, at 14:49, René J.V. Bertin rjvber...@gmail.com wrote: > But doing this you are implicitly > > You shouldn't try to extract information from a x.x.99 version number > > because it will always pass the test in your ports, regardless of whether the > user actually kept the installation up to date. Yes. We trust people that run x.x.99 to figure out what went wrong and update to the latest master. Actually, we expect people who run master to update that reasonably often, since the first answer you'll get when filing a bug against an older version of master is 'update to the latest version'. > Which will always succeed if you're using a MacPorts base built from master, > no > matter how long that was ago. Yes. In practice, that's a non-issue. - On 29 Nov, 2016, at 14:59, Rainer Müller rai...@macports.org wrote: > In the past, we often just checked for new features by testing whether > the corresponding option or proc exists. That didn't work in this particular case: https://github.com/macports/macports-ports/blob/master/archivers/deco-archive/Portfile#L23 -- Clemens Lang
Re: `git describe`
On Tuesday November 29 2016 14:59:09 Rainer Müller wrote:
>In the past, we often just checked for new features by testing whether
>the corresponding option or proc exists.
>
>if {[info exists ...]} {
Did I miss something? Checking for procedures is done with {[info procs foo] ne
""} nowadays, no?
> > What would you think of a version number of the form
> > 2.3.99-MMDD-shorthash, or 2.3.99-unixtime-shorthash?
> Probably should use committer date (%cd) instead of author date (%ad).
> The latter is not always monotonically increasing, for example when pull
> requests were rebased onto master in a different order.
If with shorthash you mean the 7 (or so) first characters from the full hash,
then that one isn't monotonically increasing either.
I've tried this kind of approach with Linux packages in my Ubuntu PPAs. Doesn't
work; more often than not dch will tell you that the new shorthash isn't newer
than the old shorthash.
If you want to use this kind of scheme linking it to a specific commit without
using `git describe` you could do x.y.99-[YY]YYMMDDhhmm[ss] . That's not longer
than adding the shorthash, and chances that multiple commits are made in a
single second (or even minute) are relatively slim (I hope).
R.
Re: `git describe`
On 2016-11-29 15:01, Davide Liessi wrote: > 2016-11-29 14:49 GMT+01:00 René J.V. Bertin : >> On Tuesday November 29 2016 13:28:27 Clemens Lang wrote: >>> You can just use >>> [vercmp $macports_version 2.3.4] > 0 >>> to check whether a bugfix you need is available. >> >> Which will always succeed if you're using a MacPorts base built from master, >> no matter how long that was ago. > > What would you think of a version number of the form > 2.3.99-MMDD-shorthash, or 2.3.99-unixtime-shorthash? > > See > git log -1 --format=%at-%h > and > git log -1 --date=format:%Y%m%d --format=%ad-%h Probably should use committer date (%cd) instead of author date (%ad). The latter is not always monotonically increasing, for example when pull requests were rebased onto master in a different order. Rainer
Re: `git describe`
2016-11-29 14:49 GMT+01:00 René J.V. Bertin : > On Tuesday November 29 2016 13:28:27 Clemens Lang wrote: >> You can just use >> [vercmp $macports_version 2.3.4] > 0 >>to check whether a bugfix you need is available. > > Which will always succeed if you're using a MacPorts base built from master, > no matter how long that was ago. What would you think of a version number of the form 2.3.99-MMDD-shorthash, or 2.3.99-unixtime-shorthash? See git log -1 --format=%at-%h and git log -1 --date=format:%Y%m%d --format=%ad-%h Best wishes. Davide
Re: `git describe`
On 2016-11-29 13:28, Clemens Lang wrote:
> You shouldn't try to extract information from a x.x.99 version number, so no,
> no
> such synchronization is required. You can just use
> [vercmp $macports_version 2.3.4] > 0
> to check whether a bugfix you need is available.
In the past, we often just checked for new features by testing whether
the corresponding option or proc exists.
if {[info exists ...]} {
... # new version
} else {
... # old version, for compatibility
}
Rainer
Re: `git describe`
On Tuesday November 29 2016 13:28:27 Clemens Lang wrote: >In which case you're missing the other reason, that is detecting newer MacPorts >versions. I have used this in the past to write and commit a Portfile that >would not work with a released version of MacPorts. Missing only in the sense that I didn't think it would happen frequently enough to consider it important. But doing this you are implicitly >You shouldn't try to extract information from a x.x.99 version number because it will always pass the test in your ports, regardless of whether the user actually kept the installation up to date. > You can just use > [vercmp $macports_version 2.3.4] > 0 >to check whether a bugfix you need is available. Which will always succeed if you're using a MacPorts base built from master, no matter how long that was ago. I'm going to drop this as it seems one of those things we'll have to agree to disagree upon. Rainer convinced me that master shouldn't use the release versions, but I haven't seen (or overlooked) any convincing argument why a master x.x.99.n versioning scheme would be a bad idea. R.
Re: `git describe`
- On 29 Nov, 2016, at 12:14, René J.V. Bertin rjvber...@gmail.com wrote: > Right now I can only think of 1 important reason why Portfiles might want to > check for the MacPorts version, and that's to detect older MacPorts versions. In which case you're missing the other reason, that is detecting newer MacPorts versions. I have used this in the past to write and commit a Portfile that would not work with a released version of MacPorts. > Wouldn't this feature plead for some form of synchronisation of > macports_version > in master with the one in the release branch? (How to handle the detection of > a > master pseudo-release version and compare it to actual releases is a follow-up > question.) You shouldn't try to extract information from a x.x.99 version number, so no, no such synchronization is required. You can just use [vercmp $macports_version 2.3.4] > 0 to check whether a bugfix you need is available. -- Clemens Lang
Re: [macports/macports-ports] cmake-1.[01].tcl: Ensure that cmake based ports use the correct compiler (#66)
On Monday November 28 2016 23:33:21 René J.V. Bertin wrote:
Taking this to the -dev ML because I hope for an answer during my regular
working hours today.
I started merging Jeremy's changes to the cmake portgroup and tested the
default configure.args thing first:
```
default configure.args {[list \
-DCMAKE_VERBOSE_MAKEFILE=ON \
-DCMAKE_COLOR_MAKEFILE=ON \
-DCMAKE_BUILD_TYPE=MacPorts \
-DCMAKE_BUILD_WITH_INSTALL_RPATH=ON \
-DCMAKE_INSTALL_NAME_DIR=${prefix}/lib \
-DCMAKE_SYSTEM_PREFIX_PATH="${prefix}\;/usr" \
-DCMAKE_MODULE_PATH=${cmake_share_module_dir} \
-DCMAKE_FIND_FRAMEWORK=LAST \
-DCMAKE_EXPORT_COMPILE_COMMANDS=ON \
{-DCMAKE_C_COMPILER=${configure.cc}} \
{-DCMAKE_CXX_COMPILER=${configure.cxx}} \
-Wno-dev
]}
```
In a test port, `ui_msg "${configure.args}"` now shows
-DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_COLOR_MAKEFILE=ON
-DCMAKE_BUILD_TYPE=MacPorts -DCMAKE_BUILD_WITH_INSTALL_RPATH=ON
-DCMAKE_INSTALL_NAME_DIR=/opt/local/lib
{-DCMAKE_SYSTEM_PREFIX_PATH="/opt/local;/usr"}
-DCMAKE_MODULE_PATH=/opt/local/share/cmake/Modules -DCMAKE_FIND_FRAMEWORK=LAST
-DCMAKE_EXPORT_COMPILE_COMMANDS=ON {-DCMAKE_C_COMPILER=${configure.cc}}
{-DCMAKE_CXX_COMPILER=${configure.cxx}} -Wno-dev
-DECM_MKSPECS_INSTALL_DIR=/opt/local/share/qt5/mkspecs/modules
-DPLUGIN_INSTALL_DIR=/opt/local/share/qt5/plugins
-DKDE_INSTALL_QTPLUGINDIR=/opt/local/share/qt5/plugins
-DQML_INSTALL_DIR=/opt/local/share/qt5/qml -DBUILD_doc=OFF -DBUILD_docs=OFF
-DBUILD_SHARED_LIBS=ON -DCMAKE_STRIP:FILEPATH=/bin/echo
-DBUNDLE_INSTALL_DIR=/Applications/MacPorts/KF5
-DCMAKE_DISABLE_FIND_PACKAGE_X11=ON -DAPPLE_SUPPRESS_X11_WARNING=ON
-DCMAKE_INSTALL_LIBEXECDIR=/opt/local/libexec
-DKDE_INSTALL_LIBEXECDIR=/opt/local/libexec/kde5 -DCMAKE_MACOSX_RPATH=ON
-DSYSCONF_INSTALL_DIR=\"/opt/local/etc\"
-DDOCBOOKXSL_DIR=/opt/local/share/xsl/docbook-xsl
-DGETTEXT_INCLUDE_DIR=/opt/local/include
-DGETTEXT_LIBRARY=/opt/local/lib/libgettextlib.dylib
-DGIF_INCLUDE_DIR=/opt/local/include -DGIF_LIBRARY=/opt/local/lib/libgif.dylib
-DJASPER_INCLUDE_DIR=/opt/local/include
-DJASPER_LIBRARY=/opt/local/lib/libjasper.dylib
-DJPEG_INCLUDE_DIR=/opt/local/include
-DJPEG_LIBRARY=/opt/local/lib/libjpeg.dylib
-DLBER_LIBRARIES=/opt/local/lib/liblber.dylib
-DLDAP_INCLUDE_DIR=/opt/local/include
-DLDAP_LIBRARIES=/opt/local/lib/libldap.dylib
-DLIBEXSLT_INCLUDE_DIR=/opt/local/include
-DLIBEXSLT_LIBRARIES=/opt/local/lib/libexslt.dylib
-DLIBICALSS_LIBRARY=/opt/local/lib/libicalss.dylib
-DLIBICAL_INCLUDE_DIRS=/opt/local/include
-DLIBICAL_LIBRARY=/opt/local/lib/libical.dylib
-DLIBINTL_INCLUDE_DIR=/opt/local/include
-DLIBINTL_LIBRARY=/opt/local/lib/libintl.dylib
-DLIBXML2_INCLUDE_DIR=/opt/local/include/libxml2
-DLIBXML2_LIBRARIES=/opt/local/lib/libxml2.dylib
-DLIBXML2_XMLLINT_EXECUTABLE=/opt/local/bin/xmllint
-DLIBXSLT_INCLUDE_DIR=/opt/local/include
-DLIBXSLT_LIBRARIES=/opt/local/lib/libxslt.dylib
-DPYTHON_EXECUTABLE=/opt/local/bin/python2.7
However, when I configure it I get the error I was half expecting:
Executing: cd
"/Volumes/VMs/MPbuild/_opt_local_site-ports_kf5_kf5-kruler/kf5-kruler/work/build"
&& /opt/local/bin/cmake -G "Unix Makefiles" -DCMAKE_INSTALL_PREFIX=/opt/local
-DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_COLOR_MAKEFILE=ON
-DCMAKE_BUILD_TYPE=MacPorts -DCMAKE_BUILD_WITH_INSTALL_RPATH=ON
-DCMAKE_INSTALL_NAME_DIR=/opt/local/lib
-DCMAKE_SYSTEM_PREFIX_PATH="/opt/local;/usr"
-DCMAKE_MODULE_PATH=/opt/local/share/cmake/Modules -DCMAKE_FIND_FRAMEWORK=LAST
-DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DCMAKE_C_COMPILER=${configure.cc}
-DCMAKE_CXX_COMPILER=${configure.cxx} -Wno-dev
-DECM_MKSPECS_INSTALL_DIR=/opt/local/share/qt5/mkspecs/modules
-DPLUGIN_INSTALL_DIR=/opt/local/share/qt5/plugins
-DKDE_INSTALL_QTPLUGINDIR=/opt/local/share/qt5/plugins
-DQML_INSTALL_DIR=/opt/local/share/qt5/qml -DBUILD_SHARED_LIBS=ON
-DCMAKE_STRIP:FILEPATH=/bin/echo
-DBUNDLE_INSTALL_DIR=/Applications/MacPorts/KF5
-DCMAKE_DISABLE_FIND_PACKAGE_X11=ON -DAPPLE_SUPPRESS_X11_WARNING=ON
-DCMAKE_INSTALL_LIBEXECDIR=/opt/local/libexec
-DKDE_INSTALL_LIBEXECDIR=/opt/local/libexec/kde5 -DCMAKE_MACOSX_RPATH=ON
-DSYSCONF_INSTALL_DIR="/opt/local/etc"
-DDOCBOOKXSL_DIR=/opt/local/share/xsl/docbook-xsl
-DGETTEXT_INCLUDE_DIR=/opt/local/include
-DGETTEXT_LIBRARY=/opt/local/lib/libgettextlib.dylib
-DGIF_INCLUDE_DIR=/opt/local/include -DGIF_LIBRARY=/opt/local/lib/libgif.dylib
-DJASPER_INCLUDE_DIR=/opt/local/include
-DJASPER_LIBRARY=/opt/local/lib/libjasper.dylib
-DJPEG_INCLUDE_DIR=/opt/local/include
-DJPEG_LIBRARY=/opt/local/lib/libjpeg.dylib
-DLBER_LIBRARIES=/opt/local/lib/liblber.dylib
-DLDAP_INCLUDE_DIR=/opt/local/include
-DLDAP_LIBRARIES=/opt/local/lib/libldap.dylib
-DLIBEXSLT_INCLUDE_DIR=/opt/local/include
-DLIBEXSLT_LIBRARIES=/opt/local/lib/libex
Re: `git describe`
>From the ChangeLog >- Added macports_version to the Portfile execution context, to allow > checking the current MacPorts version in Portfiles. > (cal in r134511) Right now I can only think of 1 important reason why Portfiles might want to check for the MacPorts version, and that's to detect older MacPorts versions. Anything else can probably be caught with "we only support running the latest version" (be it the latest release or the latest master/head). Wouldn't this feature plead for some form of synchronisation of macports_version in master with the one in the release branch? (How to handle the detection of a master pseudo-release version and compare it to actual releases is a follow-up question.) R.
Re: Porting software that wants to build/install its own language bindings
On 29 November 2016 at 02:21, Lawrence Velázquez wrote: >> On Nov 28, 2016, at 7:31 PM, A. Karl Kornel wrote: >> >> I am looking for advice on how best to handle a port for a program >> that wants to build its own language bindings. >> >> I am writing a port for a program called "hivex", which is a tool and >> an API for manipulating Windows Registry "hive" files. The API is >> written in C, but it also is able to build support for Perl, Python, >> OCaml, and Ruby. >> >> What makes this confusing is that additional language support is added >> by `configure` switches (like --with-python and --without-ocaml), so >> I don't think separate Portfiles would be the best option here. I'm >> also not sure if subports would work either. Did you check what exactly these options change? In case of OCaml I would just provide a variant that would allow someone to avoid a dependency on OCaml. In case of Perl, Python, Ruby, ... I would first check what exactly the port installs and what it offers. If the bindings are meant to be used in *other* software, like for example in a perl or python script that a user writes himself, then supporting subports like p5.24-hivex (and p5.26-hivex once a new version of perl gets released) would make more sense. Sadly, if the upstream doesn't offer any easy way to do that, you would have to compile the whole software and just put the relevant bits to destdir. If you just need Perl in the port itself, it makes more sense to provide a variant. > As Brandon already said, it's common to use variants for this. Ports > that do this include boost, postgresql*, root[56], xapian-bindings, and > vim/MacVim (among many others). ROOT is a particularly bad example (I would say a counterexample) of a port using python variants. I would say that there are two kinds of ports that require python: 1.) Ports that simply need *any* version of python to be functional 1.A) among those ports where support for Python 3 is still experimental (and developer might want to be able to experiment and report problems upstream) 1.B) or ports where python is optional 2.) Ports that install python modules that are useful elsewhere In the first case using a variant is much better (or no variant at all if any version of python just works). In the second case it's better to use subports. In case of ROOT, the port installs a python module that is supposed to be used in standalone python scripts written by users. So it would be much much better if the port would be split into - root6 - py27-root6 - py35-root6 etc. The problem is that it's non-trivial to install py**-root[56] outside of the main installer. It would be super easy if upstream would support that. At the moment the only way other that diving into the source and make heavy modifications would be to compile root[56] four times, once for the main port and three other times for three python subports. And then remove anything that's already installed by the main port in post-destroot phase. But that would be super resource hungry (compiling root6 means compiling the latest clang + many more classes). > A few ports do use subports or separate ports; these include > subversion-* and swig. If you can manage it, this setup is best because > other ports can then declare dependencies on your bindings (they cannot > properly depend on variants), but it might require more work on your > part. Depending on the build system, each subport might have to do > a full build while only installing the bindings and discarding > everything else. Yes, sadly that might sometimes be the only option. If it's built on the buildbot or if the software is small enough, that's a bit less of a problem for your users. Mojca
Re: `git describe`
On Tuesday November 29 2016 03:15:03 Ryan Schmidt wrote: >> Then you have your answer in fact. When you bump the version in that script >> you can use git-release or equivalent to create a 2.4.99 tag, and from there >> on `git describe` would identify master as 2.4.99-- . >> That'd be almost exactly what I'd like to see (though later rather than >> sooner). > >We don't want a x.x.99 tag. It wouldn't mean anything. x.x.99 means master. It >doesn't mean any specific state of master. I don't follow, if x.x.99 means master and a file in master returns that string, why not also add the tag to the git data? It's the same information, but more easily accessible with certain tools (and the macports_version script could simply return the value obtained from git). Also, if x.x.99 doesn't mean "any specific state", why does it change with major releases? That's not me arguing, I really don't understand, all the more since there is already a tag that implies a "specific state of master" that seems even more inappropriate than an x.x.99 tag could possible be. >No, I would not consider adding such tags. Sorry, I meant to use the plural form of "you" ;) R
Re: [macports-ports] branch master updated: appstream-glib: Fix build failure by using correct CPPFLAGS
> On Nov 29, 2016, at 01:03, Ryan Schmidt wrote:
>
>
>> On Nov 29, 2016, at 2:37 AM, Jeremy Huddleston Sequoia
>> wrote:
>>
>> Jeremy Huddleston Sequoia (jeremyhu) pushed a commit to branch master
>> in repository macports-ports.
>>
>>
>> https://github.com/macports/macports-ports/commit/9cf09de33536f93f76d622ef8d6acf7d72dbcaac
>>
>> The following commit(s) were added to refs/heads/master by this push:
>>
>> new 9cf09de appstream-glib: Fix build failure by using correct CPPFLAGS
>>
>> 9cf09de is described below
>>
>>
>> commit 9cf09de33536f93f76d622ef8d6acf7d72dbcaac
>>
>> Author: Jeremy Huddleston Sequoia
>> AuthorDate: Tue Nov 29 00:37:12 2016 -0800
>>
>>
>> appstream-glib: Fix build failure by using correct CPPFLAGS
>
>> @@ -47,7 +47,7 @@ configure.cmd ./autogen.sh
>> # configure to use system libuuid
>> configure.env-append \
>> -UUID_CFLAGS=-I/usr/include/uuid \
>> +UUID_CFLAGS='-iwithsysroot /usr/include/uuid' \
>
> What's -iwithsysroot? I've never heard of that one.
-iwithsysroot means "Use this directory, prefixed by -isysroot if one is
specified" as a system header path
-isysroot ${SDKROOT} -iwithsysroot /usr/include/uuid
is equivalient to
-isysroot ${SDKROOT} -isystem ${SDKROOT}/usr/include/uuid
---
This is basically a build fix for folks that don't have a DevSDK (eg:
installing Xcode without CommandLineTools).
--Jeremy
smime.p7s
Description: S/MIME cryptographic signature
Re: `git describe`
> On Nov 29, 2016, at 2:57 AM, René J.V. Bertin wrote: > > On Monday November 28 2016 17:25:39 Ryan Schmidt wrote: > >> That's correct and intentional. > > I also said that that version complied with practices I see elsewhere :) > >> It was changed to 2.3.99 after we created the 2.3 release branch, which was >> 2 years ago. After we create a 2.4 release branch, the version on master >> will be changed to 2.4.99. > > Then you have your answer in fact. When you bump the version in that script > you can use git-release or equivalent to create a 2.4.99 tag, and from there > on `git describe` would identify master as 2.4.99-- . > That'd be almost exactly what I'd like to see (though later rather than > sooner). We don't want a x.x.99 tag. It wouldn't mean anything. x.x.99 means master. It doesn't mean any specific state of master. > Would you consider adding an additional level by 2.3.6 (= 2.3.99.6) so that > the master version keeps some form of synchronisation with the release > version? I don't think that it suggests master is based on 2.3.X, but it does > convey the message that 2.3.X contains things that were introduced into > master before 2.3.99.X. No, I would not consider adding such tags.
Re: [macports-ports] branch master updated: appstream-glib: Fix build failure by using correct CPPFLAGS
> On Nov 29, 2016, at 2:37 AM, Jeremy Huddleston Sequoia > wrote: > > Jeremy Huddleston Sequoia (jeremyhu) pushed a commit to branch master > in repository macports-ports. > > > https://github.com/macports/macports-ports/commit/9cf09de33536f93f76d622ef8d6acf7d72dbcaac > > The following commit(s) were added to refs/heads/master by this push: > > new 9cf09de appstream-glib: Fix build failure by using correct CPPFLAGS > > 9cf09de is described below > > > commit 9cf09de33536f93f76d622ef8d6acf7d72dbcaac > > Author: Jeremy Huddleston Sequoia > AuthorDate: Tue Nov 29 00:37:12 2016 -0800 > > > appstream-glib: Fix build failure by using correct CPPFLAGS > @@ -47,7 +47,7 @@ configure.cmd ./autogen.sh > # configure to use system libuuid > configure.env-append \ > -UUID_CFLAGS=-I/usr/include/uuid \ > +UUID_CFLAGS='-iwithsysroot /usr/include/uuid' \ What's -iwithsysroot? I've never heard of that one.
Re: `git describe`
On Monday November 28 2016 17:25:39 Ryan Schmidt wrote: >That's correct and intentional. I also said that that version complied with practices I see elsewhere :) >It was changed to 2.3.99 after we created the 2.3 release branch, which was 2 >years ago. After we create a 2.4 release branch, the version on master will be >changed to 2.4.99. Then you have your answer in fact. When you bump the version in that script you can use git-release or equivalent to create a 2.4.99 tag, and from there on `git describe` would identify master as 2.4.99-- . That'd be almost exactly what I'd like to see (though later rather than sooner). Would you consider adding an additional level by 2.3.6 (= 2.3.99.6) so that the master version keeps some form of synchronisation with the release version? I don't think that it suggests master is based on 2.3.X, but it does convey the message that 2.3.X contains things that were introduced into master before 2.3.99.X. R.
