Updates in fink's git master.

I've just put some updates into the fink master branch 
(https://github.com/fink/fink)

The major changes are as follows:

1) bootstrap will work if users on Lion have just the Xcode Command Line 
Tools, and not the full Xcode.
2) The gcc* virtual packages have been tightened up a bit.  The only 
versions that show as potentially installable on a given OS version are 
those which can be installed via the Xcode installer for that OS 
version, e.g. gcc4.2 is listed on 10.5, because Xcode 3.1 has it, 10.6, 
because Xcode 3.2.x has it, and 10.7, because Xcode 4.1 has it.
3) There is now a clang virtual package, which shows up as a potential 
option on 10.6 and later.  Translated into a fink version and revision, 
"Apple clang version 3.1 (tags/Apple/clang-318.0.58)" becomes 
clang-3.1-3.18.0.58.
4) There is now an llvm-gcc virtual package, which shows up as a 
potential option on 10.6 and later.  Translated into a fink version and 
revision, "i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple 
Inc. build 5658) (LLVM build 2336.9.00)" becomes llvm-gcc-4.2.1-2336.9.00.

If people try it, and I don't get any bad reports, I'll do a release in 
a couple of days.

--

-- 
Alexander Hansen, Ph.D.
Fink User Liaison
http://finkakh.wordpress.com/2012/02/21/got-job/

------------------------------------------------------------------------------

Re: Changing fink-obsolete-packages dependencies to RuntimeDepends

On Mar 29, 2012, at 5:27 AM, Max Horn wrote:

> Dear all,
> a small clarification:
> 
> 
> Am 28.03.2012 um 17:46 schrieb Max Horn:
> 
>> Dear package authors,
>> 
>> I would like to suggest the following to all package authors using
>> 
>> Depends: fink-obsolete-packages
>> 
>> in an obsolete splitoff in one of their packages: Namely, please switch to using
>> 
>> Depends: fink (>= 0.32)
>> RuntimeDepends: fink-obsolete-packages
> 
> This should be
>  BuildDepends: fink (>= 0.32)
>  RuntimeDepends: fink-obsolete-packages

Max,

Does this apply for splitoffs only, or for standalone info files as well?

Example: Buildbot split into master and slave packages upstream. There is a buildbot-py.info that
depends on fink-obsolete-packages and the two new separate .info files.

Re: Changing fink-obsolete-packages dependencies to RuntimeDepends

On 4/3/12 6:23 PM, Charles Lepple wrote:
> On Mar 29, 2012, at 5:27 AM, Max Horn wrote:
>
>> Dear all,
>> a small clarification:
>>
>>
>> Am 28.03.2012 um 17:46 schrieb Max Horn:
>>
>>> Dear package authors,
>>>
>>> I would like to suggest the following to all package authors using
>>>
>>> Depends: fink-obsolete-packages
>>>
>>> in an obsolete splitoff in one of their packages: Namely, please switch to using
>>>
>>> Depends: fink (>= 0.32)
>>> RuntimeDepends: fink-obsolete-packages
>> This should be
>>   BuildDepends: fink (>= 0.32)
>>   RuntimeDepends: fink-obsolete-packages
>
> Max,
>
> Does this apply for splitoffs only, or for standalone info files as well?
>
> Example: Buildbot split into master and slave packages upstream. There is a buildbot-py.info that
depends on fink-obsolete-packages and the two new separate .info files.
>

Suggested packages

Dear Fink Developers,

I would like to contribute two science packages to Fink 10.7:
- sci/grib-api (ECMWF GRIB API)
- sci/cdo (Climate Data Operators)
The latter used to appear in Fink 10.6 but has no maintainer and was not ported to 10.7.

I'm running both packages for while with success. I'd be willing to become the maintainer of these packages
(tell me how), or someone can pick them up below.

Regards,
Remko

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2

_______________________________________________
Fink-devel mailing list

Re: Suggested packages

On 4/9/12 2:41 PM, Remko Scharroo wrote:
> Dear Fink Developers,
>
> I would like to contribute two science packages to Fink 10.7:
> - sci/grib-api (ECMWF GRIB API)
> - sci/cdo (Climate Data Operators)
> The latter used to appear in Fink 10.6 but has no maintainer and was not ported to 10.7.
>
> I'm running both packages for while with success. I'd be willing to become the maintainer of these
packages (tell me how), or someone can pick them up below.
>
> Regards,
> Remko
>
>
How to become the maintainer would be to put your name and preferred 
email address in the Maintainer field, and send the files with those 
changes. 

--

-- 
Alexander Hansen, Ph.D.
Fink User Liaison
http://finkakh.wordpress.com/2012/02/21/got-job/

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________

gcc46 vs gcc47

   In case package maintainers are wondering if the new gcc47 package contains
code generation improvements making it worthwhile to upgrade their packages from
a dependency on gcc46 to gcc47, here are the results from the Polyhedron 2005
benchmarks with the most exhaustive optimizations of -Ofast -unroll-loops -flto
-fwhole-program. Note that the -Ofast option includes -fstack-arrays and
-fno-protect-parens so any code compiled with that should be checked with its
testsuite.

================================================================================
Date & Time     :  9 Apr 2012 21:27:00
Test Name       : gfortran46_lin_O3_Ofast_wholeprogram
Compile Command : gfortran-fsf-4.6 -Ofast -funroll-loops -flto -fwhole-program %n.f90 -o %n
Benchmarks      : ac aermod air capacita channel doduc fatigue gas_dyn induct linpk mdbx nf protein rnflow
test_fpu tfft
Maximum Times   :     2000.0
Target Error %  :      0.100
Minimum Repeats :    10
Maximum Repeats :   100

   Benchmark   Compile  Executable   Ave Run  Number   Estim
        Name    (secs)     (bytes)    (secs) Repeats   Err %
   ---------   -------  ----------   ------- -------  ------
          ac      6.77       50896     10.68      13  0.0272
      aermod     85.90     1172288     22.34      14  0.0888
         air      5.83       74176      7.57      20  0.0975
    capacita      4.79       73104     39.74      14  0.0796
     channel      1.87       34864      2.24      13  0.0603
       doduc     14.28      188152     38.03      14  0.0256
     fatigue      4.73       81480     10.78      13  0.0570
     gas_dyn      8.67      115784      6.84      18  0.0751

switch to framework python builds?

Daniel and Daniel,
  While creating test packaging for a wxcocoa923-py package for use
with relax-py, I discovered that the cocoa build of wxPython 9.2.3.1
issues an error message, when running its demos, that access to the
screen requires a framework build of python for the cocoa support.
Since MacPorts already builds their pythons as frameworks, I'll 
continue testing there to make sure that the resulting wxPython
with cocoa support is fully functional. If it is, we really might
want to consider switching our python packages over to framework
builds as well in order to be able to use the upcoming cocoa support
in such packages as wxPython.
          Jack

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Fink-devel mailing list
Fink-devel <at> lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: switch to framework python builds?

Isn't the actual only difference between "framework" and "library" the 
difference between using -F/-framework vs -L/-l flags when linking? And 
the binary library inside .framework is really just a .dylib by a 
different filenaming scheme. I can't envision any way that the linker 
flags or filename/location could have any runtime effect at all, or 
that any runtime-loading or configure-detection/makefile recipe 
couldn't just have its flags changed to the normal-lib way. 

dan

On Wed, 11 Apr 2012 10:43:46 -0400, Jack Howarth 
<howarth <at> bromo.med.uc.edu> wrote:
Daniel and Daniel,
>   While creating test packaging for a wxcocoa923-py package for use
> with relax-py, I discovered that the cocoa build of wxPython 9.2.3.1
> issues an error message, when running its demos, that access to the
> screen requires a framework build of python for the cocoa support. 
> Since MacPorts already builds their pythons as frameworks, I'll 
> continue testing there to make sure that the resulting wxPython
> with cocoa support is fully functional. If it is, we really might
> want to consider switching our python packages over to framework
> builds as well in order to be able to use the upcoming cocoa support
> in such packages as wxPython. 
>           Jack
>
>

  --
Daniel Macks
dmacks <at> netspace.org

Re: switch to framework python builds?

On Wed, Apr 11, 2012 at 11:04:05AM -0400, Daniel Macks wrote:
> Isn't the actual only difference between "framework" and "library" the  
> difference between using -F/-framework vs -L/-l flags when linking? And  
> the binary library inside .framework is really just a .dylib by a  
> different filenaming scheme. I can't envision any way that the linker  
> flags or filename/location could have any runtime effect at all, or that 
> any runtime-loading or configure-detection/makefile recipe couldn't just 
> have its flags changed to the normal-lib way. 
>
> dan

Dan,
   It is unclear why wxPython is now demanding python frameworks. On their 
web page http://www.wxpython.org/download-2.6.3.3.php, it says...

 Mac OS X

 wxPython needs a special Mac OS X-specific build of Python, called a Framework build, in order to work.
Panther and Tiger include a Framework build of Python 2.3, but on Jaguar you'll need to get the MacPython
installer from Jack's MacPython page. 

 Note to Fink users: Versions of Python installed by Fink cannot run wxPython (unless you install and run
X11...). You need to use Apple's Framework builds, or a third-party Framework build. 

but it unclear if this really is only intended for users of prebuilt wxPython 2.9.x binaries. 
However in http://www.wxpython.org/recentchanges.php, it mentions...

 Added the ability to the build tools to make a Mac Framework for wxWidgets, and use it in the wxPython build.
(We're still ironing out some issues so it's not part of the release builds yet.)

Re: switch to framework python builds?

On Apr 11, 2012, at 11:04 AM, Daniel Macks <dmacks <at> netspace.org> wrote:

> Isn't the actual only difference between "framework" and "library" the difference between using
-F/-framework vs -L/-l flags when linking? And the binary library inside .framework is really just a
.dylib by a different filenaming scheme. I can't envision any way that the linker flags or
filename/location could have any runtime effect at all, or that any runtime-loading or
configure-detection/makefile recipe couldn't just have its flags changed to the normal-lib way.
> dan

Yes, it's just a matter of packaging. I'd bet though that wxcocoa
assumes that python is always a framework on OS X and only looks
there. It'll probably need patching.

Now there is another difference between fink's and system python; the
system's uses system tcltk which uses cocoa while fink's uses fink's
tcltk which uses x11. I don't know if that's an issue.

In any case, changing our python packages would require changing all
packages that link to them. That's a lot more work than fixing one
package. :)

Daniel

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Fink-devel mailing list