Re: [Fink-devel] scons 1.2 into stable
> >Can we have the newer scons 1.2 release moved > > from unstable into stable? The stable release is > > very old (0.98) and appears to be misbuilding > > the relax-py package (which uses scons to build). > > Jack > > We'll give the maintainer (cc'ed) a chance to express assent. Go ahead ! Indeed 0.98 is getting really old ... /v -- Vincent Beffara UMPA - ENS-Lyon 46 allée d'Italie 69364 Lyon Cedex 07 Tél : 04 72 72 85 25 -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Upgrading IPE
Hi all, I would be interested in adopting and maintaining the IPE graphics software for fink. Making an .info file for it is kind of on the way (a few minor things to tweak), but I have a few questions. - there is an antiquated version (6.0pre) in the repository, with package name ipe6. It depends on a few other old packages, most notably tetex and qt3. Besides, it is maintained by None. Not sure how many people are using it, but it should probably be marked obsolete at some point. Am I allowed to adopt it and prepare for that ? - about the package name. I would be tempted to simply use 'ipe' with version 7.0.10 but 'ipe7' is an option as well, which would match the previous one. What is the policy on that, if there is one ? - the package depends on qt4. I tried to build against the version provided by Apple, but it seems to be 32-bit only IIUC. So, I depend on fink's qt4. In order to use qt4-mac, it seems necessary to make an .app (probably in /sw/Applications copying the behavior of qgit) - is that standard procedure ? - Related, I couldn't find an answer online: any way to convince a Qt binary to take focus on command-line launch, besides replacing it with a launcher for a .app bundle ? Thanks for your help in this ! Cheers, /vincent -- Vincent Beffara UMPA - ENS-Lyon 46 allée d'Italie 69364 Lyon Cedex 07 Tél : 04 72 72 85 25 -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Upgrading IPE
Hi, > The original package is named 'ipe6' because it builds shared libraries > as well (ipe6-shlibs). I'd recommend making the library package > ipe7-shlibs for consistency, but you're welcome to call the main package > "ipe". OK, so I will do that. > > - the package depends on qt4. I tried to build against the version > > provided by Apple, > > Apple provides Qt4? News to me. Ah, maybe I was a bit quick in my interpretation. I have /Library/Frameworks/QtCore.framework in my system, and I made the mental shortcut "not in my home dir and not in /sw means it's Apple". I remember now that I did install these libs as a package at some point. Sorry about that. Thanks again ! /v -- Vincent Beffara UMPA - ENS-Lyon 46 allée d'Italie 69364 Lyon Cedex 07 Tél : 04 72 72 85 25 -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Upgrading IPE
Hello, > > The original package is named 'ipe6' because it builds shared libraries > > as well (ipe6-shlibs). I'd recommend making the library package > > ipe7-shlibs for consistency, but you're welcome to call the main package > > "ipe". > > More critically, what is the install_name of the library? If it is > still libipe.1.dylib (same as ipe6) then package-name remains the > same. If it changes, package-name must change. No clue why ipe_6_ was > chosen for _1_.dylib, but now we're stuck with that for it, and you > can make your own choice about what new package-name to use if that > filename will be different. ipe_6_ was chosen (I can only guess) because the program version was 6.0.something and referred to as ipe6. And actually separating the shlibs out was done to follow the packaging rules, but I don't know if anyone ever saw anything else than ipe use them ;-) For consitstency, I chose to use libipe.7.dylib as install_name and so ipe7-shlibs as corresponding package name. The actual software does not really do anything about it (without a patch the install_name ends up being ../../build/src/libipe.so.5.0.10 or something like that). BTW, if ipe7-shlib is a splitoff of ipe, and there is an upgrade of ipe upstream with a different major version, and I end up having ipe8-shlibs as a splitoff of a new version of ipe, then nobody can build ipe7-shlibs anymore, which sounds a little bad. So I will go for ipe7 as package name. Is it allowed to create a package 'ipe' which does nothing but depend on ipe7 (and later on ipe8 in case of an upgrade), or are such things reserved for developers higher in the food chain ? Or am I simply wrong in wanting the package name to match the software name without a version number attaached to it ? Thanks for all your help, /v -- Vincent Beffara UMPA - ENS-Lyon 46 allée d'Italie 69364 Lyon Cedex 07 Tél : 04 72 72 85 25 -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Upgrading IPE
> > For consitstency, I chose to use libipe.7.dylib as install_name > > and so ipe7-shlibs as corresponding package name. The actual > > software does not really do anything about it (without a patch the > > install_name ends up being ../../build/src/libipe.so.5.0.10 or > > something like that). > > I'd recommend being consistent with _upstream_ then, and setting the > install_name as libipe.5.dylib. Ooops, I meant libipe.so.7.0.10 of course ! > > BTW, if ipe7-shlib is a splitoff of ipe, and there is an upgrade of > > ipe upstream with a different major version, and I end up having > > ipe8-shlibs as a splitoff of a new version of ipe, then nobody can > > build ipe7-shlibs anymore, which sounds a little bad. So I will go > > for ipe7 as package name. > > No, it should still be possible to build ipe7-shlibs. One way to do it > is to have the version number on the .info file. Ah, I hadn't thought of that. So I do ipe7.info declaring ipe (with version 7.x.y) and ipe7-shlibs as a splitoff, and if ever necessary I will do ipe8.info declaring ipe again (with version 8.x.y) and ipe8-shlibs as a splitoff, and Fink will not be confused by two descriptions of ipe in two different files. That makes a lot of sense, actually. Thanks for all the advice ! /v -- Vincent Beffara UMPA - ENS-Lyon 46 allée d'Italie 69364 Lyon Cedex 07 Tél : 04 72 72 85 25 -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Upgrading IPE
> Ooh wait, is "ipe" the headers used for building against the
> "ipeX-shlibs" package? If so, the headers package must never change
> which -shlibs it's associated with. Otherwise, other packages that
> want to use ipe won't be able to control or know which library they
> get.
No, 'ipe' is a GUI for drawing figures. It relies on a shared library
which it is essentially the only package to use, but can be used to
extend it through plugins ('ipelets'). There are headers associated to
it, which I will of course put in ipe7-dev. A plugin package would
depend on the ipe7-shlibs package and build-depend on ipe7-dev (and the
plugin would be very likely to need deep rewriting should the major
version ever increase).
/v
--
Vincent Beffara
UMPA - ENS-Lyon
46 allée d'Italie
69364 Lyon Cedex 07
Tél : 04 72 72 85 25
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] SCons in stable
Hi list, Not sure whom to contact about this - my SCons 1.2 package was recently promoted into the stable tree, but unfortunately the patch file associated to it (devel/scons.patch) was not included. So SCons does not build in the stable confguration, which is not optimal. Can somebody here fix it ? If not, who do I talk to about it ? [I can't, as I don't have write access to the tree.] Thanks in advance, /v -- Vincent Beffara UMPA - ENS-Lyon 46 allée d'Italie 69364 Lyon Cedex 07 Tél : 04 72 72 85 25 -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Trying to make an ipe.info
Hi (salut),
NB> Ipe is already running under MacPorts (I don't have MacPorts
NB> installed). I compiled and installed ipe7 under Fink with the aid of
NB> some dependent libraries that could be installed from Fink
NB> (unstable), like cairo and freetype2. I used the Apple QtCore and
NB> QtGui (the config.mak was allowing such a setting for OS/X 10.6).
I did the same myself at some point, I am attaching what I did so far so
that you can compare ... The issue is that .so is the dynamic library
extension in linux, and not in darwin, but that is not very problematic
in itself, you just need to tell fink to shut up about it, or have the
build process rename the file to something.dylib and make ipe look for
.dylib files rather than .so ones [I do the second thing].
ipe.info
Description: Binary data
diff --git a/OSX/Info.plist b/OSX/Info.plist
new file mode 100644
index 000..92f58db
--- /dev/null
+++ b/OSX/Info.plist
@@ -0,0 +1,24 @@
+
+http://www.apple.com/DTDs/PropertyList-1.0.dtd";>
+
+
+ CFBundleDevelopmentRegion
+ English
+ CFBundleExecutable
+ ipe
+ CFBundleGetInfoString
+ ipe v. 7.0.12
+ CFBundleIdentifier
+ net.sourceforge.ipe7
+ CFBundleInfoDictionaryVersion
+ 6.0
+ CFBundleName
+ ipe
+ CFBundlePackageType
+ APPL
+ CFBundleShortVersionString
+ ipe v. 7.0.12
+ CFBundleVersion
+ 1.0.1
+
+
diff --git a/OSX/ipe b/OSX/ipe
new file mode 100644
index 000..b7e48e3
--- /dev/null
+++ b/OSX/ipe
@@ -0,0 +1,6 @@
+#!/bin/sh
+
+export IPE_PWD=`pwd`
+export IPE_ARGS="$*"
+
+open -a _SW_/Applications/ipe.app
diff --git a/OSX/ipe_wrapper b/OSX/ipe_wrapper
new file mode 100644
index 000..7bfc3f4
--- /dev/null
+++ b/OSX/ipe_wrapper
@@ -0,0 +1,5 @@
+#!/bin/sh
+
+cd $IPE_PWD
+
+exec $0.bin $IPE_ARGS
diff --git a/src/common.mak b/src/common.mak
index 7fe5059..c196542 100644
--- a/src/common.mak
+++ b/src/common.mak
@@ -105,11 +105,13 @@ else
soname = -Wl,-soname,lib$1.so.$(IPEVERS)
endif
buildlib = $(BUILDDIR)/lib
- dll_target= $(buildlib)/lib$1.so.$(IPEVERS)
- dll_symlinks = ln -sf lib$1.so.$(IPEVERS) $(buildlib)/lib$1.so
- install_symlinks = ln -sf lib$1.so.$(IPEVERS) \
- $(INSTALL_ROOT)$(IPELIBDIR)/lib$1.so
- ipelet_target = $(BUILDDIR)/ipelets/$1.so
+ dll_target= $(buildlib)/lib$1.$(IPEVERS).dylib
+ soname= -install_name _SW_/lib/lib$1.7.dylib -compatibility_version $(IPEVERS) -current_version $(IPEVERS)
+ dll_symlinks = ln -sf lib$1.$(IPEVERS).dylib $(buildlib)/lib$1.7.dylib && \
+ ln -sf lib$1.7.dylib $(buildlib)/lib$1.dylib
+ install_symlinks = ln -sf lib$1.$(IPEVERS).dylib $(INSTALL_ROOT)$(IPELIBDIR)/lib$1.7.dylib && \
+ ln -sf lib$1.7.dylib $(INSTALL_ROOT)$(IPELIBDIR)/lib$1.dylib
+ ipelet_target = $(BUILDDIR)/ipelets/$1.dylib
exe_target = $(BUILDDIR)/bin/$1
endif
diff --git a/src/config.mak b/src/config.mak
index b6bed04..487afdc 100644
--- a/src/config.mak
+++ b/src/config.mak
@@ -52,9 +52,10 @@ else
CONFIG += x86_64
LUA_CFLAGS = $(shell pkg-config --cflags lua)
LUA_LIBS = $(shell pkg-config --libs lua)
-QT_CFLAGS = -I/Library/Frameworks/QtCore.framework/Versions/4/Headers \
- -I/Library/Frameworks/QtGui.framework/Versions/4/Headers
-QT_LIBS= -F/Library/Frameworks -L/Library/Frameworks \
+QT_CFLAGS = -I_SW_/lib/qt4-mac/lib/QtCore.framework/Versions/4/Headers \
+ -I_SW_/lib/qt4-mac/lib/QtGui.framework/Versions/4/Headers \
+ -I_SW_/lib/qt4-mac/include
+QT_LIBS= -F_SW_/lib/qt4-mac/lib -L_SW_/lib/qt4-mac/lib \
-framework QtCore -framework ApplicationServices \
-framework QtGui -framework AppKit -framework Cocoa -lz -lm
MOC = moc
diff --git a/src/ipelua/ipeluaipelet.cpp b/src/ipelua/ipeluaipelet.cpp
index 8d6c806..55ddd0e 100644
--- a/src/ipelua/ipeluaipelet.cpp
+++ b/src/ipelua/ipeluaipelet.cpp
@@ -67,7 +67,7 @@ int ipelua::ipelet_constructor(lua_State *L)
#ifdef WIN32
fname += ".dll";
#else
- fname += ".so";
+ fname += ".dylib";
#endif
ipeDebug("Loading dll '%s'", fname.z());
PNewIpeletFn pIpelet = 0;
One tricky thing to make ipe more mac-friendly is to wrap it inside an
App bundle, and make it still launchable by typing "ipe toto.ipe" in a
terminal. That requires packing ARGV and the current working directory
in the environment before calling 'open'.
Maybe I should have put that in the tracker ...
HTH,
/v
--
| | UMPA - ENS Lyon | Mél: vbeff...@ens-lyon.fr |
| Vincent Beffara | 46 allée d'Italie | Tél: (+33) 4 72 72 85 25 |
| | 69364 Lyon Cedex 07 | Fax: (+33) 4 72 72 84 80 |
--
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself;
WebMatrix provides all the features you need to develop and publish
your website. http://p.sf.net/sfu/ms-webmatr
Re: [Fink-devel] glob2 update to version 0.9.1, help required
> Hello,
Hi,
> I recently submitted glob2 version 0.8.23, and it was accepted in unstable.
> Now a new mainstream version is available, which is 0.9.1.
> The build system was changed in order to use scons.
>
> The new package builds fine, and it works when I build it outside of fink.
> Now using fink, after building succesfully, I get an error when I try to
> launch glob2, as it seems it does not find a file it is looking for.
>
> My question is about the information I need to give when building the
> package. I have attached the info file, and my problem is that I am not
> sure it is right to give options BINDIR=%i/bin and INSTALLDIR=%i/share, as
> once the package is installed, glob2 will have to look in %p/share, but may
> be still looking in %i/share...
Yep, that's a typical problem, and the reason for the whole $DESTDIR
part of auto{make,conf}. The basic thing that works with make, i.e.
"make prefix=/sw ; make install prefix=/sw/src/root-glob2/sw" or
whatever the directory should be, doesn't work because SCons is too
smart, and will recompile at that point.
Looking at the SConstruct, you can see 2 relevant variables :
- INSTALLDIR : used at install time, so you want this to be
/sw/src/root/whatever/sw/share, i.e. %i/share
- PACKAGE_DATA_DIR : this is where glob2 will look for files at runtime,
so you want it to be /sw/share, i.e. %p/share
And the SConstruct file allows you to do just that: the default value of
PACKAGE_DATA_DIR is $INSTALL, which makes sense for a simple install,
but you can override it on the command-line, the same way you do
INSTALL. In other words:
scons INSTALLDIR=%i/share BINDIR=%i/bin PACKAGE_DATA_DIR=%p/share
though you might have to move the relevant line near the one about
INSTALL. If all else fails you can always patch SConstruct to set the
variable by force, with a perl command or something. [Not with the fink
patch mechanism though, because you want %p instead of /sw - or use the
patch mechanism to write '%p/share' and then perl -e "s/\%p/%p".]
Yet another way is to add a DESTDIR variable, defaulting to '', and use
it where relevant. That would be a little bit more work I guess, but
would feel less hacked somehow, and you could then send a patch upstream
and be in the credits :-)
BTW, commenting "exit 1" lines might not be the best idea, are you sure
you can't have them work instead ? From what you say, it sounds like
either CPPPATH or LIBPATH is set too late, which should be fixable.
HTH, and come back if it doesn't,
/vincent
--
Vincent Beffara
UMPA - ENS Lyon
46 Allée d'Italie
69364 LYON cedex 07
Tel: 04 72 72 85 25
Fax: 04 72 72 84 80
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] glob2 update to version 0.9.1, help required
Hi again,
> Thanks for the suggestion, but I failed to make it work.
>
> I added the following lines in Sconstruct :
>
> opts.Add("DATA_DIR", "Data Directory", "/sw/share")
>
> configfile.add("PACKAGE_DATA_DIR", "data directory", "\"" +
> env["DATA_DIR"] + "\"")
>
> and modified in the info file CompileScript :
>
> scons CXXFLAGS="-I%p/include -I%p/include/boost-1_34_1 -I/usr/X11R6/include
> " LINKFLAGS="-L%p/lib" osx="true" BINDIR=%i/bin INSTALLDIR=%i/share
> DATA_DIR=%p/share
>
> but there is actually no effect.
I am attaching something that works. Besides doing something reasonable
with %i/%d/%p it also enables OpenGL and sets release=1 (i.e. -O3). The
game is MUCH nicer with them :-)
But please remain the maintainer of the package!
> I also agree that commenting "exit 1" is not really clean, but as I do not
> understand why some .h are found and not the others, I will stay with this
> for now.
Mmmmkay, so most of them are fixed by doing
env.Append(CPPPATH=["/sw/include"]) and env.Append(LIBPATH=["/sw/lib"])
instead of setting them as CXXFLAGS. The reason being that SCons is
clever enough to look for header files without having to call gcc (or so
I believe) so CXXFLAGS is not actually used to look for them.
Only the OpenGL thing is problematic, and that seems to be a known
problem: g++ finds OpenGL/gl.h somewhere, but SCons doesn't. So I
removed those lines from the script altogether and set HAVE_OPENGL by
hand instead.
General question ti Fink developers, not glob2-specific:
BTW, one very nice thing about SCons is CacheDir() where it stores
object files and such. Setting this to be outside of the build dir (say
in /tmp or something) makes it possible to keep the cache across various
versions of a package. For packaging and debugging, it saves a lot of
time (second compilation is something like 15 seconds total).
Would it be a good idea to fix some canonical location
(/sw/var/cache/scons_cache) for it ?
Cheers,
/v
--
Vincent Beffara
UMPA - ENS Lyon
46 Allée d'Italie
69364 LYON cedex 07
Tel: 04 72 72 85 25
Fax: 04 72 72 84 80
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] glob2 update to version 0.9.1, help required
> I am attaching something that works.
Hmm, well, _this_ time I am attaching them, sorry for the double post...
/v
--
Vincent Beffara
UMPA - ENS Lyon
46 Allée d'Italie
69364 LYON cedex 07
Tel: 04 72 72 85 25
Fax: 04 72 72 84 80
Package: glob2
Version: 0.9.1
Revision: 1
GCC: 4.0
Architecture: powerpc, i386
Maintainer: Alexandre Vial <[EMAIL PROTECTED]>
Depends: libvorbis0-shlibs, sdl-image-shlibs, sdl-ttf-shlibs, sdl-net-shlibs,
speex3-shlibs, boost1.34.nopython-shlibs, fribidi-shlibs
BuildDepends: scons, vorbis-tools, libvorbis0, libogg, sdl, sdl-image, sdl-ttf,
sdl-net, speex3, boost1.34.nopython, fribidi, fribidi-dev
Conflicts:
Source: http://dl.sv.nongnu.org/releases/%n/%v/%n-%v.tar.gz
Source-MD5: 507da29c310f199f9b1a9a5f335b7a7a
SourceDirectory: glob2-%v
Patch: %n.patch
CompileScript: <<
scons osx=1 release=1 INSTALLDIR=%i/share BINDIR=%i/bin
DATADIR=%p/share/glob2 FINKPREFIX=%p
<<
InstallScript: <<
scons install
<<
DocFiles: AUTHORS COPYING README README.hg TODO INSTALL
InfoDocs:
Description: Innovative Real-Time Strategy (RTS) game
DescDetail: <<
Globulation 2 brings a new type of gameplay to RTS games. The player chooses
the number of units to assign to various tasks, and the units do their best
to satisfy the requests. This allows players to manage more units and focus on
strategy rather than individual unit's jobs. Globulation 2 also features AI
allowing single-player games or any possible combination of human-computer
teams. Also included is a scripting language for versatile gameplay or
tutorials and an integrated map editor. Globulation2 can be played in single
player mode, through your local network, or over the Internet with
Ysagoon Online Gaming (or YOG for short).
To play, type glob2 in Terminal.app.
<<
DescPort: <<
Scons does not find some files when checking, but compiling is ok, so exit
lines are commented.
<<
Homepage: http://www.globulation2.org/
License: GPL
diff -ruN glob2-0.9.1-orig/SConstruct glob2-0.9.1/SConstruct
--- glob2-0.9.1-orig/SConstruct 2007-09-02 05:14:53.0 +0200
+++ glob2-0.9.1/SConstruct 2007-09-14 00:10:19.0 +0200
@@ -4,12 +4,17 @@
opts.Add("LINKFLAGS", "Manually add to the LINKFLAGS", "")
opts.Add("INSTALLDIR", "Installation Directory", "/usr/local/share")
opts.Add("BINDIR", "Binary Installation Directory", "/usr/local/bin")
+opts.Add("DATADIR", "Final destination of data files", "/usr/local/share")
+opts.Add("FINKPREFIX", "Fink directory", "/sw")
opts.Add(BoolOption("release", "Build for release", 0))
opts.Add(BoolOption("mingw", "Build with mingw enabled if not
auto-detected", 0))
opts.Add(BoolOption("osx", "Build for OSX", 0))
Help(opts.GenerateHelpText(env))
opts.Update(env)
opts.Save('options_cache.py', env)
+
+env.Append(CPPPATH = [ env["FINKPREFIX"] + "/include" ])
+env.Append(LIBPATH = [ env["FINKPREFIX"] + "/lib"])
class Configuration:
@@ -29,7 +34,7 @@
configfile = Configuration()
configfile.add("PACKAGE", "Name of package", "\"glob2\"")
configfile.add("PACKAGE_BUGREPORT", "Define to the address where bug
reports for this package should be sent.", "\"[EMAIL PROTECTED]"")
-configfile.add("PACKAGE_DATA_DIR", "data directory", "\"" +
env["INSTALLDIR"] + "\"")
+configfile.add("PACKAGE_DATA_DIR", "data directory", "\"" + env["DATADIR"]
+ "\"")
configfile.add("PACKAGE_SOURCE_DIR", "source directory", "\""
+env.Dir("#").abspath.replace("\\", "") + "\"")
configfile.add("PACKAGE_NAME", "Define to the full name of this package.",
"\"Globulation 2\"")
configfile.add("PACKAGE_TARNAME", "Define to the one symbol short name of
this package.", "\"glob2\"")
@@ -93,11 +98,6 @@
gl_libraries.append("GL")
elif conf.CheckLib('opengl32') and conf.CheckCHeader('GL/gl.h'):
gl_libraries.append("opengl32")
-else:
-#Quick fix for OSX, ignore libraries not found
-if not env['osx']:
-print "Could not find libGL or opengl32, or could not find GL/gl.h
or OpenGL/gl.h"
-Exit(1)
#Do checks for GLU, which is different on every system
if conf.CheckLib('GLU') and conf.CheckCHeader("GL/glu.h"):
@@ -106
Re: [Fink-devel] system-texlive
Hi, > >> I am finishing up my work on a system-texlive package. It will > >> also > >> have tetex-base-texlive and tetex-texmf-texlive packages. That's great to hear ! > > If I understand well, the latter two build everything from source ? > Nope, they depend on system-texlive, provide tetex-base and tetex- > texmf (respectively), and also depend on a few other things that > teTeX provides but TeX Live does not. They're both non-source > packages. Maybe naming them tetex-base-system-texlive would be better then (in addition to competing for the longest package name). Are you considering a texlive (i.e. from source) package as well ? Or is that an obviously bad idea ? One advantage would be sharing of the texmf tree with additional Fink packages. But compiling TeXlive is likely to be non-trivial ... /v -- Vincent Beffara UMPA - ENS-Lyon 46 allée d'Italie 69364 Lyon Cedex 07 Tél : 04 72 72 85 25 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] unison packages
> > Is it possible to move current (2.13.16) version to stable branch of > > fink and update unstable to have 2.27.XX? > > It appears that the only missing dependency is lablgtk (unmaintained), > so if there aren't any objections, I can go ahead and move our > existing unison package to stable. Unison used to be violently incompatible across versions (both ways, there is AFAIK no way to have 2.09 talk to 2.13). I'm not sure it's still the case, as their API might have converged since then, but some people who update-all without looking might get bitten by that ... Especially since recompiling on the opposite end is not trivial at all if OCaml is not present. /v -- Vincent Beffara UMPA - ENS-Lyon 46 allée d'Italie 69364 Lyon Cedex 07 Tél : 04 72 72 85 25 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Python patch for offlineimap
> > For earlier versions of Python, there is a way to fix OfflineIMAP > > without hacking on Python; see my patch in the issue tracker. Vincent, > > what do you think of including my patch in Fink's OfflineIMAP until > > Python 2.5.3 is released and distributed by Fink? At that time, we can > > remove the patch and add a dependency on python25 (>= 1:2.5.2-1) . > > I like that idea :) OK, I was thinking of doing precisely that actually. I will look into it as soon as I find a few hours. BTW, yesterday I put version 5.99.8 on the tracker. So that will be for version 5.99.8-2 I guess - unless version 6 is released first ;-) /v -- Vincent Beffara UMPA - ENS-Lyon 46 allée d'Italie 69364 Lyon Cedex 07 Tél : 04 72 72 85 25 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] Python patch for offlineimap
> This bug has already been reported to the OfflineIMAP folks: > http://software.complete.org/software/issues/show/20 . Apparently the > bug in Python is fixed, so this problem will no longer occur with > Python 2.5.3 and higher. However, contrary to the impression given by > the issue tracker, earlier versions of Python (including the python25 > in Fink) do not have the fix so far as I can tell. > > For earlier versions of Python, there is a way to fix OfflineIMAP > without hacking on Python; see my patch in the issue tracker. Vincent, > what do you think of including my patch in Fink's OfflineIMAP until > Python 2.5.3 is released and distributed by Fink? At that time, we can > remove the patch and add a dependency on python25 (>= 1:2.5.2-1) . Mmkay, I applied your patch, plus a similar one of mine for the non-ssl behavior (which also produced the same kind of crash). I am attaching the file. At least it doesn't crash for me anymore using IMAP, but I don't have access to an IMAPS server at this time, so I will trust you on that part. I will show it to the offlineimap mailing list too and attach it to the tracker item of fink (which is currently delayed, with good reason, precisely because of its crashing behavior). /vincent -- Vincent Beffara UMPA - ENS Lyon 46 Allée d'Italie 69364 LYON cedex 07 Tel: 04 72 72 85 25 Fax: 04 72 72 84 80 diff --git a/offlineimap/imapserver.py b/offlineimap/imapserver.py index 4e37ece..ac39b77 100644 --- a/offlineimap/imapserver.py +++ b/offlineimap/imapserver.py @@ -23,6 +23,8 @@ from threading import * import thread, hmac, os import base64 +from StringIO import StringIO + try: # do we have a recent pykerberos? have_gss = False @@ -60,10 +62,38 @@ class UsefulIMAP4(UsefulIMAPMixIn, imaplib.IMAP4): def open(self, host = '', port = imaplib.IMAP4_PORT): imaplibutil.new_open(self, host, port) +# This is a hack to go around Darwin's implementation of +# realloc(), which Python uses inside the socket class. If a message +# is larger than 1M, we get it piece by piece instead of all at +# once. + +def read(self, size): +read = 0 +io = StringIO() +while read < size: +tmp = size-read +if (tmp>100): tmp=100 +data = self.file.read(tmp) +read += len(data) +io.write(data) +return io.getvalue() + class UsefulIMAP4_SSL(UsefulIMAPMixIn, imaplibutil.WrappedIMAP4_SSL): def open(self, host = '', port = imaplib.IMAP4_SSL_PORT): imaplibutil.new_open_ssl(self, host, port) +# This is the same thing as above, except we can be a little bit +# more clever by avoiding the socket class altogether. + +def read(self, size): +read = 0 +io = StringIO() +while read < size: +data = self.sslobj.read(size-read) +read += len(data) +io.write(data) +return io.getvalue() + class UsefulIMAP4_Tunnel(UsefulIMAPMixIn, imaplibutil.IMAP4_Tunnel): pass class IMAPServer: - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] Python patch for offlineimap
Hi there, There were quite a few people who wrote to me about this particular crash these last few weeks; apparently what I uploaded to the tracker fixed only the non-SSL access. So I finally installed an IMAPS server, and it did exhibit the crash, even when accessed locally. I tweaked the patch some more, and once again "it works for me" now ... But I am not sure how robust it is, esp. with truly remote servers. Is anyone on this list both affected by the crash and brave enough to test the attached info file and associated patch, before I submit it to the tracker ? Thanks, /v -- Vincent Beffara UMPA - ENS Lyon 46 Allée d'Italie 69364 LYON cedex 07 Tel: 04 72 72 85 25 Fax: 04 72 72 84 80 diff --git a/offlineimap/imapserver.py b/offlineimap/imapserver.py index 4e37ece..2f0119e 100644 --- a/offlineimap/imapserver.py +++ b/offlineimap/imapserver.py @@ -23,6 +23,9 @@ from threading import * import thread, hmac, os import base64 +from StringIO import StringIO +from platform import system + try: # do we have a recent pykerberos? have_gss = False @@ -60,10 +63,42 @@ class UsefulIMAP4(UsefulIMAPMixIn, imaplib.IMAP4): def open(self, host = '', port = imaplib.IMAP4_PORT): imaplibutil.new_open(self, host, port) +# This is a hack around Darwin's implementation of realloc() (which +# Python uses inside the socket code). On Darwin, we split the +# message into 100k chunks, which should be small enough - smaller +# might start seriously hurting performance ... + +def read(self, size): +if system() == 'Darwin': +read = 0 +io = StringIO() +while read < size: +data = self.file.read(min(size-read,10)) +read += len(data) +io.write(data) +return io.getvalue() +else: +return self.file.read(size) + class UsefulIMAP4_SSL(UsefulIMAPMixIn, imaplibutil.WrappedIMAP4_SSL): def open(self, host = '', port = imaplib.IMAP4_SSL_PORT): imaplibutil.new_open_ssl(self, host, port) +# This is the same hack as above, to be used in the case of an SSL +# connexion. + +def read(self, size): +if system() == 'Darwin': +read = 0 +io = StringIO() +while read < size: +data = self.sslobj.read(min(size-read,10)) +read += len(data) +io.write(data) +return io.getvalue() +else: +return self.sslobj.read(size) + class UsefulIMAP4_Tunnel(UsefulIMAPMixIn, imaplibutil.IMAP4_Tunnel): pass class IMAPServer: Package: offlineimap Version: 5.99.11 Revision: 2 Maintainer: Vincent Beffara <[EMAIL PROTECTED]> HomePage: http://software.complete.org/offlineimap License: GPL Description: Mailbox synchronization tool Source: mirror:debian:pool/main/o/%n/%n_%v.tar.gz Source-MD5: 4a5369593ab386a9776f8a95e2cb9b6a PatchFile: %n.patch PatchFile-MD5: fe6e3025f632fdadf989f150625429bc SourceDirectory: offlineimap Depends: python25 BuildDepends: docbook-utils, fink (>= 0.24.12) CompileScript: << %p/bin/python2.5 setup.py build %p/bin/docbook2man offlineimap.sgml %p/bin/docbook2man offlineimap.sgml << InstallScript: << %p/bin/python2.5 setup.py install --prefix=%p --root=%d mkdir -p %i/share/man/man1 cp offlineimap.1 %i/share/man/man1 << DocFiles: COPYING COPYRIGHT FAQ.html README UPGRADING offlineimap.conf* offlineimap.sgml - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] Python patch for offlineimap
> > Is anyone on this list both affected by the crash and brave enough to > > test the attached info file and associated patch, before I submit it to > > the tracker ? > > I was affected by it with SSL, and now am not. Just tested downloading a 7Mb > email over IMAPS and it all seems to work fine. Excellent ! The new version + new patch are on the tracker. I also submitted the patch "upstream" for inclusion - not everyone that has a Mac is using Fink, even though they should ;-) Cheers, /v -- Vincent Beffara UMPA - ENS-Lyon 46 allée d'Italie 69364 Lyon Cedex 07 Tél : 04 72 72 85 25 pgpJRvacdWwZI.pgp Description: PGP signature - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] (La)TeX and Fink (Was: New packages in tracker)
> > Clearly, if I get that far, I would need people to test this for me, > > resp. review what I did. > > I like this idea and would be willing to test it. Same here. BTW, how does e.g. debian package TeXlive exactly ? If they already split it into manageable sub-packages (and I seem to remember that they did for tetex when I used it), some trouble can be avoided by "plagiarizing" what they do ... It's FOSS after all ! /v -- Vincent Beffara UMPA - ENS-Lyon 46 allée d'Italie 69364 Lyon Cedex 07 Tél : 04 72 72 85 25 pgp1Xaxx04Iwe.pgp Description: PGP signature - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
[Fink-devel] Fwd: Re: (La)TeX and Fink (Was: New packages in tracker)
(oops, wrong e-mail ...) > I believe that the following is true: > > Debian gets around a bunch of the problems that Fink has by only > distributing binaries. Thus you can use whatever build environment you > need, and do crazy build things, and not have to worry about whether it > will integrate with the rest of Fink. Well in the case of texlive, there certainly seems to be plenty of stuff in the debian/ subdirectory, but you _can_ build the packages yourself if you want ... and the splitting looks reasonable, see there http://packages.debian.org/source/sid/texlive-base (Not saying that this is a trivial thing to do, but the package descriptions in debian and fink are not that different, from what I understand.) Anyway, I will have access to a debian (well ubuntu) system pretty soon, I will have a look at the build process. /v -- Vincent Beffara UMPA - ENS-Lyon 46 allée d'Italie 69364 Lyon Cedex 07 Tél : 04 72 72 85 25 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] PyObjC 2.1 package in the tracker
Hi, > > One option is to make a tarball up and post it somewhere until the mirrors > > pick it up. > > That's what I've done for now. Glad to know that was ok :) Nevertheless, the general question is interesting in itself. What to do if one wants to follow the SVN version of a package ? Can one assume that the build machine will have network access ? (It kind of has to if only to download the source tarball, but I can imagine scenarios where you download lots of sources in bulk and then compile while on the road ...) I am interested in something similar myself, and thought essentially of two solutions : (i) ship a base tarball that is close to the SVN trunk, and make a patch script that calls SVN to catch up to a prescribed revision number. The base tarball might be empty but it's not nice to the server ... (ii) ship a base tarball that is close to the SVN trunk, and make a patch script that calls SVN to catch up with the trunk itself. Then the .deb file depends on the compilation date, which is wrong for distribution but useful for a local package, as "fink rebuild" will then automate most of it. Solution (i) sounds acceptable, but it would be fantastic to have fields like Repository: and Revision: in finkinfo file ! And solution (ii), to be implementable properly, would need to compute the package version number from the current revision, which afaik is not doable right now. Anyway, it's too hot to think properly these days ... Cheers, /v -- Vincent Beffara UMPA - ENS-Lyon 46 allée d'Italie 69364 Lyon Cedex 07 Tél : 04 72 72 85 25 pgpbEv3dJvVZl.pgp Description: PGP signature - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] PyObjC 2.1 package in the tracker
> > (i) ship a base tarball that is close to the SVN trunk, and make a patch > > script that calls SVN to catch up to a prescribed revision number. The > > base tarball might be empty but it's not nice to the server ... > > An acceptable method (that has been used by some packages) is to get the > diff to an svn or cvs version and make a patch file from it. Sure, that's doable, but it becomes quite tedious if you want to track a fast-moving project ... Are you implying that it is _not_ acceptable to call svn (or cvs or git or whatever) from the patch script ? /v -- Vincent Beffara UMPA - ENS-Lyon 46 allée d'Italie 69364 Lyon Cedex 07 Tél : 04 72 72 85 25 - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] PyObjC 2.1 package in the tracker
> > > > (i) ship a base tarball that is close to the SVN trunk, and make a > > > > patch script that calls SVN to catch up to a prescribed revision > > > > number. The base tarball might be empty but it's not nice to the server > > > > ... > > > > > > An acceptable method (that has been used by some packages) is to get the > > > diff to an svn or cvs version and make a patch file from it. > > > > Sure, that's doable, but it becomes quite tedious if you want to track a > > fast-moving project ... Are you implying that it is _not_ acceptable to > > call svn (or cvs or git or whatever) from the patch script ? > > > > /v > > That violates a central paradigm of Fink: a package description should > produce identical build results on different machines (as much as possible). Agreed, but this is not what I meant - I mean calling svn with a specific revision number (which would of course also be part of the fink version number). Then the result _is_ guaranteed to be the same. Would that be acceptable ? /v -- Vincent Beffara UMPA - ENS-Lyon 46 allée d'Italie 69364 Lyon Cedex 07 Tél : 04 72 72 85 25 - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] Pangocairo and XCode 3.1: do they tango?
> Juan Courcoul wrote: > > A few days ago I asked on Fink Users if it was safe to update to XCode > > 3.1 and at the moment there was no serious impediment and important > > benefits. Then pangocairo landed Since this seems to be where > > most of the bloody carnage ( :D ) seems to be happening, guess it's > > the place to re-ask. > > The only problem with xcode-3.1 I know of is with X11. The X11SDK.pkg > from xcode-3.1 has some incompatibilities with the rest of Leopard's > X11. So if you manage to install xcode-3.1 without installing its > X11SDK.pkg, it should be OK. I don't remember if this is possible by > unselecting X11 in the custom install window. If not, try to find your > xcode-3.0 disk image and look for its X11SDK.pkg, so that you can > reinstall it after the installation of xcode-3.1. > > Another possibility is to install the latest xquartz/macosforge X11 > update after the installation of xcode-3.1. I can testify that this works pretty well, if done in that order (XCode, then Xquartz, then upgrade to pangocairo). I only had to launch update-all twice, and everything looks fine now, after about 20 hours of compiling. One potential danger would be that XCode 3.1 contains several versions of gcc, and switching between them in the middle of the upgrade might mess things up a bit ... /v -- Vincent Beffara UMPA - ENS-Lyon 46 allée d'Italie 69364 Lyon Cedex 07 Tél : 04 72 72 85 25 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] Create a redistribuitable .dmg image from a compiled program
Hi, > It created a working independent redistributable dmg for me. > I think it would be a nice thing for qt apps built in fink. Do you mean that the whole Qt framework is contained in the app ? That sounds a bit overkill ... /v -- Vincent Beffara UMPA - ENS-Lyon 46 allée d'Italie 69364 Lyon Cedex 07 Tél : 04 72 72 85 25 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] scons and Depends
Hi, I am the maintainer of the fink package for SCons. >I noticed that scons doesn't allow a Depends > and wondering if this had been thought through > enough. It hasn't. More precisely, I don't remember if I took over this package or if I copied that for another build tool, but setting builddependsonly to true is not a deeply thought out decision of mine in any case. I can remove the corresponding line if it helps. However, plenty of python packages are compiled at compile time on not at postinstall time ... Is there anything special in your case that makes the usual approach unusable ? Do the generated .pyc files fail to load somehow ? /v -- Vincent Beffara UMPA - ENS Lyon 46 Allée d'Italie 69364 LYON cedex 07 Tel: 04 72 72 85 25 Fax: 04 72 72 84 80 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
