Re: Compile/Link 101
On Oct 4, 2013, at 9:39 PM, Craig Treleaven wrote: > I actually don't know how the test _can succeed_ with XCode 5? There is no > '-L' flag to indicate that the library is under /opt/local/lib. MacPorts sets the LIBRARY_PATH environment variable in the configure phase, which sufficiently recent compilers take into account when linking. I don't know exactly when Clang started respecting it. vq ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Compile/Link 101
Could someone please explain some very basic stuff about
compiling/linking C and C++ code? For a new version of Myth, the
configure script succeeds with XCode 5 on Mtn Lion and _fails_ with
XCode 4.3 on Lion. The bit that I'm looking at just tests whether
certain libraries (faac in this case) are installed and, if so,
enables additional features in the package. The 'config.ep' file
(btw, is that a Unix/Linux standard thingy?) shows how it tried to do
the test:
BEGIN
/opt/local/var/macports/build/_Users_mytthtv_macports_mythtv-core.27_dev/mythtv-core.27/work/.tmp/mythtv_conf.xUGXlOJK.c
1 #include
2 #include
3 long check_faacEncGetVersion(void) { return (long) faacEncGetVersion; }
4 int main(void) { return 0; }
END
/opt/local/var/macports/build/_Users_mytthtv_macports_mythtv-core.27_dev/mythtv-core.27/work/.tmp/mythtv_conf.xUGXlOJK.c
/usr/bin/clang -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE -D_DARWIN_C_SOURCE -DPIC -pipe -std=c99
-fomit-frame-pointer -fPIC -c -o
/opt/local/var/macports/build/_Users_mytthtv_macports_mythtv-core.27_dev/mythtv-core.27/work/.tmp/mythtv_conf.CaP65ZOS.o
/opt/local/var/macports/build/_Users_mytthtv_macports_mythtv-core.27_dev/mythtv-core.27/work/.tmp/mythtv_conf.xUGXlOJK.c
/usr/bin/clang -Wl,-dynamic,-search_paths_first -o
/opt/local/var/macports/build/_Users_mytthtv_macports_mythtv-core.27_dev/mythtv-core.27/work/.tmp/mythtv_conf.7NGrnBrt
/opt/local/var/macports/build/_Users_mytthtv_macports_mythtv-core.27_dev/mythtv-core.27/work/.tmp/mythtv_conf.CaP65ZOS.o
-lfaac -lm -lbz2 -lz
ld: library not found for -lfaac
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
ERROR: libfaac not found
faac _is_ installed:
MediaMini:~ mytthtv$ port installed |grep aac
faac @1.28_2 (active)
I actually don't know how the test _can succeed_ with XCode 5? There
is no '-L' flag to indicate that the library is under /opt/local/lib.
I must be missing something obvious. Pointers to introductory
material gratefully accepted.
Craig
--
--
Craig Treleaven, CA -- Clearview Consulting
(905) 829-2054 ctrelea...@cogeco.ca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [MacPorts] XcodeVersionInfo deleted version
On Oct 4, 2013, at 15:38, Eric Gallager wrote: > On Fri, Oct 4, 2013 at 2:47 PM, Jeremy Lavergne wrote: >> After some version, the OS is now "OS X" and no longer "Mac OS X" > Yeah, that's Mountain Lion My understanding is that Apple retroactively renamed Lion from Mac OS X to OS X, hence I changed the wiki page to reflect that. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [111870] trunk/dports/devel/kmm_banking/Portfile
On Oct 4, 2013, at 8:41 PM, Joshua Root wrote: > Why bump the revision when it fails to build either way? If this depends > on a port that no longer exists, shouldn't it just be deleted? (If > anyone has an older version of aqbanking installed, it will be > automatically deactivated and replaced with aqbanking5…) You are right, I'll look into that. I am sorry for unnecessarily reverting the change. kmm_banking should be made obsolete itself. Greets, Marko ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [MacPorts] XcodeVersionInfo deleted version
Yeah, that's Mountain Lion On Fri, Oct 4, 2013 at 2:47 PM, Jeremy Lavergne wrote: > After some version, the OS is now "OS X" and no longer "Mac OS X" > > > ___ > macports-dev mailing list > macports-dev@lists.macosforge.org > https://lists.macosforge.org/mailman/listinfo/macports-dev > ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [MacPorts] XcodeVersionInfo deleted version
After some version, the OS is now "OS X" and no longer "Mac OS X" ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
[111870] trunk/dports/devel/kmm_banking/Portfile
> Revision: 111870 > https://trac.macports.org/changeset/111870 > Author: mk at macports.org > Date: 2013-10-04 11:16:26 -0700 (Fri, 04 Oct 2013) > Log Message: > --- > kmm_banking: revert change made in r111867, because aqbanking5 isn't usable > with kmm_banking [make use of kmymoney4(-devel) instead] > > Revision Links: > -- > https://trac.macports.org/changeset/111867 > > Modified Paths: > -- > trunk/dports/devel/kmm_banking/Portfile > > Modified: trunk/dports/devel/kmm_banking/Portfile > === > --- trunk/dports/devel/kmm_banking/Portfile 2013-10-04 18:14:22 UTC (rev > 111869) > +++ trunk/dports/devel/kmm_banking/Portfile 2013-10-04 18:16:26 UTC (rev > 111870) > @@ -7,7 +7,7 @@ > # this is specific to this port and *version* for downloading it > set release 09 > > -revision1 > +revision2 > > categories devel net kde finance > license GPL-2 > @@ -27,7 +27,7 @@ > sha13507c62d4d9e2a1427ef594d5b5f59a277ae8bc9 \ > rmd160 03e798e4fa2ccbe497f22d598d1f6da517f3ba9d > > -depends_lib port:aqbanking5 \ > +depends_lib port:aqbanking \ Why bump the revision when it fails to build either way? If this depends on a port that no longer exists, shouldn't it just be deleted? (If anyone has an older version of aqbanking installed, it will be automatically deactivated and replaced with aqbanking5...) - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
New wiki page describing commit rules needed or nonsense?
I figured that a section about rules concerning properly formatted commit messages are missing in the wiki (not to talk about the Guide), which is why I created the following page: https://trac.macports.org/wiki/CommitRules below the committers guide https://trac.macports.org/wiki/CommittersGuide In case I am mistaken and the information is already present, but hidden someplace else, please let me know. Greets, Marko ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: suggestion for Fortran recipe
I think it was Sean Farley, so I'm explicitly adding him on cc to this
conversation...
On Fri, Oct 4, 2013 at 10:32 AM, Jeremy Huddleston Sequoia <
jerem...@macports.org> wrote:
> Yeah, that sounds reasonable.
>
> As for the PortGroup, IIRC, someone was working on a general compilers
> PortGroup which would incorporate this.
>
> On Oct 3, 2013, at 18:47, David Strubbe wrote:
>
> > Hi Jeremy and others,
> >
> > I think a few lines can be simplified in the new Fortran recipe. For
> default variants, it seems to me that it makes no difference whether it is
> set when the variant was explicitly selected.
> >
> > i.e this code from the Portfile recipe
> >
> > if {![variant_isset q8] && ![variant_isset q32]} {
> > default_variants +q16
> > }
> >
> > is functionally equivalent to
> >
> >
> > if {![variant_isset q8] && ![variant_isset q16] && ![variant_isset q32]}
> {
> > default_variants +q16
> > }
> >
> > since if +q16 is selected it is not important whether we consider that
> choice to have been made by default or not.
> >
> > As a result, in the Fortran recipe,
> >
> > if {[variant_isset gcc${ver_no_dot}]} {
> > if {${default_fortran_variant} != "+gcc${ver_no_dot}"} {
> > set default_fortran_variant ""
> > }
> > }
> >
> > is equivalent in functionality to
> >
> > if {[variant_isset gcc${ver_no_dot}]} {
> > set default_fortran_variant ""
> > }
> >
> > and the corresponding if-condition can be removed in the g95 statement,
> thus removing some lines and simplifying it.
> >
> > I am also wondering, can't the Fortran recipe be made a PortGroup? It
> seems problematic for the maintainability of the portfiles for there to be
> such a large block duplicated in many portfiles. If it were a PortGroup,
> then issues like the one above could be settled centrally.
> >
> > Best,
> > David
>
>
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: suggestion for Fortran recipe
Yeah, that sounds reasonable.
As for the PortGroup, IIRC, someone was working on a general compilers
PortGroup which would incorporate this.
On Oct 3, 2013, at 18:47, David Strubbe wrote:
> Hi Jeremy and others,
>
> I think a few lines can be simplified in the new Fortran recipe. For default
> variants, it seems to me that it makes no difference whether it is set when
> the variant was explicitly selected.
>
> i.e this code from the Portfile recipe
>
> if {![variant_isset q8] && ![variant_isset q32]} {
> default_variants +q16
> }
>
> is functionally equivalent to
>
>
> if {![variant_isset q8] && ![variant_isset q16] && ![variant_isset q32]} {
> default_variants +q16
> }
>
> since if +q16 is selected it is not important whether we consider that choice
> to have been made by default or not.
>
> As a result, in the Fortran recipe,
>
> if {[variant_isset gcc${ver_no_dot}]} {
> if {${default_fortran_variant} != "+gcc${ver_no_dot}"} {
> set default_fortran_variant ""
> }
> }
>
> is equivalent in functionality to
>
> if {[variant_isset gcc${ver_no_dot}]} {
> set default_fortran_variant ""
> }
>
> and the corresponding if-condition can be removed in the g95 statement, thus
> removing some lines and simplifying it.
>
> I am also wondering, can't the Fortran recipe be made a PortGroup? It seems
> problematic for the maintainability of the portfiles for there to be such a
> large block duplicated in many portfiles. If it were a PortGroup, then issues
> like the one above could be settled centrally.
>
> Best,
> David
smime.p7s
Description: S/MIME cryptographic signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: a-port-devel: what is the good practice
On Oct 4, 2013, at 02:07, Joël Brogniart wrote: > I'd like to add a new port for the developer version of the > auto-multiple-choice application based on a recent subversion version. What > are the best practices? > > - Should I define the port for the last subversion revision or for a specific > revision? > - If the port is defined for a specific revision, how often should I update > the port: once a month, more frequently, less frequently, at will? > - What are your advice for a devel port? You must specify a specific revision because builds must be reproducible. Unless the developers actually have a strategy of releasing a number of development builds before a new stable build, we usually only create devel ports when there's a particular need, for example a new feature or bugfix that you want to test that hasn't been released in a stable version yet. How often to update the port is up to you. For example you might stop updating the port altogether once you've verified the feature or bugfix works, and once the next stable version incorporating it is released, you might retire the devel port. With most of my devel ports, like glib2-devel, pango-devel, cairo-devel, libpixman-devel, when I update is dictated by when the developers release a new development version. With one of them though, graphviz-devel, new development versions are released automatically every 24 hours, so I don't update the port quite that often; I tend to update that one about every 10 days, but that's because I'm quite interested in graphviz. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
a-port-devel: what is the good practice
Hello, I'd like to add a new port for the developer version of the auto-multiple-choice application based on a recent subversion version. What are the best practices? - Should I define the port for the last subversion revision or for a specific revision? - If the port is defined for a specific revision, how often should I update the port: once a month, more frequently, less frequently, at will? - What are your advice for a devel port? Thanks for your attention, Joël Brogniart signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
