Re: [Fink-devel] gcc4x/gcc4x-compiler packages
Daniel, Why do you say that 'info /sw/share/info/gcc-fsf-4.5' is need? With my currently proposed packaging a simple 'info gcc-fsf-4.5' is sufficient to find the renamed info file in /sw/share/info with or without the main gcc45 symlink package installed. Jack -- ___ 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] gcc4x/gcc4x-compiler packages
On Wed, Apr 28, 2010 at 09:15:18AM -0400, Jack Howarth wrote: Daniel, Why do you say that 'info /sw/share/info/gcc-fsf-4.5' is need? With my currently proposed packaging a simple 'info gcc-fsf-4.5' is sufficient to find the renamed info file in /sw/share/info with or without the main gcc45 symlink package installed. As mentioned several email ago, xrefs from one .info to another. For example, in the gcj info page in the Invoking gcj node is a link to the Option Summary node of the gcc info page. You have gcj at gcj-fsf-4.5 and gcc at gcc-fsf-4.5. If I don't have gcc4.5 installed, then I only have gcc-fsf-4.5 (not gcc) and the link is broken. If I have gcc4.4 (or any other than 4.5 gcc) installed, then the link goes to *that* gcc, not the 4.5 one (i.e., gcj-fsf-4.5 is sending me to a symlink to gcc-fsf-4.4 rather than gcc-fsf-4.5). That's the problem I'm trying to solve. If the documentation isn't self-consistent (from the perspective of the reader), it's not useful/usable. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- ___ 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] gcc4x/gcc4x-compiler packages
On 04/27/2010 12:08 AM, Jack Howarth wrote: I've posted test packaging for a gcc45-4.5.0-1001 and gcc45-compiler-4.5-1 package on fink tracking... https://sourceforge.net/tracker/?func=detailaid=2992713group_id=17203atid=414256 The new gcc45 packaging... 1) Moves all of the currently conflicting files between the gcc4x packages into a new gcc4x-compiler package which recreates them with symlinks. 2) Builds the compiler programs with the -fsf-4.x suffix and presents these program names in %p/bin via symlinks in the main gcc4x package. 3) Provides all of the original program names in %p/lib/gcc4.x/bin. I've tested this packaging by upgrading from the previous gcc45-4.5.0-1000 proposed packaging. A test gcc46 package of the same type was also used to verify that the gcc45/gcc46 packages properly co-exist and that the two gcc45-compiler/gcc46-compiler packages properly switch the default FSF gcc system compiler in %p/bin as well as the associated man and info pages. Jack Hi Jack, I don't get it. Why create a new -compiler package with the old compiler names as symlinks and require everyone to modify their builddepends? Can you not do it all in one .info file, install all the symlinks in your installscript, and then splitoff the -shlibs and the real compilers etc., leaving only the old symlinks in the gcc45 package. This would keep compatibility with the current packaging while allowing all the real compilers to be simultaneously installed. i.e. gcc45 package contains all the links you have just put in gcc45-compiler gcc45-shlibs contains all the shlibs gcc45-toolchain (or some better name) has everything else. Sorry, I thought that was what you were planning to do, or I would have mentioned it yesterday. Peter -- ___ 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] gcc4x/gcc4x-compiler packages
On Tue, Apr 27, 2010 at 09:24:42AM -0500, Peter O'Gorman wrote: On 04/27/2010 12:08 AM, Jack Howarth wrote: I've posted test packaging for a gcc45-4.5.0-1001 and gcc45-compiler-4.5-1 package on fink tracking... https://sourceforge.net/tracker/?func=detailaid=2992713group_id=17203atid=414256 The new gcc45 packaging... 1) Moves all of the currently conflicting files between the gcc4x packages into a new gcc4x-compiler package which recreates them with symlinks. 2) Builds the compiler programs with the -fsf-4.x suffix and presents these program names in %p/bin via symlinks in the main gcc4x package. 3) Provides all of the original program names in %p/lib/gcc4.x/bin. I've tested this packaging by upgrading from the previous gcc45-4.5.0-1000 proposed packaging. A test gcc46 package of the same type was also used to verify that the gcc45/gcc46 packages properly co-exist and that the two gcc45-compiler/gcc46-compiler packages properly switch the default FSF gcc system compiler in %p/bin as well as the associated man and info pages. Jack Hi Jack, I don't get it. Why create a new -compiler package with the old compiler names as symlinks and require everyone to modify their builddepends? Can you not do it all in one .info file, install all the symlinks in your installscript, and then splitoff the -shlibs and the real compilers etc., leaving only the old symlinks in the gcc45 package. This would keep compatibility with the current packaging while allowing all the real compilers to be simultaneously installed. i.e. gcc45 package contains all the links you have just put in gcc45-compiler gcc45-shlibs contains all the shlibs gcc45-toolchain (or some better name) has everything else. Sorry, I thought that was what you were planning to do, or I would have mentioned it yesterday. Peter Peter, The problem is that the current handling of dependencies in fink doesn't allow that. Read the thread Could not resolve inconsistent dependencies in the fink-devel mailing list. It is impossible to come up with a split-off strategy that allows for clean upgrades from the existing gcc4x packages. If there is a lot of push-back against changing the current and prior gcc4x packages in the same manner, we could just start this with gcc45 and all future gcc4x releases. To recap, the problem with using a single package with split-off strategy is that both gcc4x and gcc4x-bin would require a Conflicts/ Replaces on the older gcc4x packages which have overlapping files. This is because the older gcc4x packages can't know that they are are able co-exist with the newer gcc4x package and will Conflict with it. This causes dependency failures for fink in the absence of an explicit Conflicts/Replaces in the new gcc4x package (which is impossible since gcc4x-bin also needs that). The solution is to move the overlapping files out of gcc4x into a gcc4x-compiler package and have the new gcc4x package Conflicts/Replaces with the older gcc4x packages while the gcc4x-compiler package Depends on a newer gcc4x package which doesn't have overlapping files. When you actually start trying to run these upgrades yourself, you see how impossible the single package approach is. Jack ps It isn't like this demands any significant effort from the other developers. They can just change the existing BuildDepends from gcc4x to gcc4x-compiler or leave the BuildDepends as gcc4x and either change the compiler inovations from gcc-4 to gcc-fsf-4.x or explicitly use the path %p/lin/gcc4.x/bin/gcc-4. I think I've left everyone with plenty of options here. I would also note that we would probably be violating fink policy by trying to add a gcc4x-bin split-off that only contained symlinks. Also, the reason I want to implement this change is that packages that currently require the gcc4x package to be present (including the upcoming dragonegg-gcc package) end up causing fink remove failures with the use of one gcc4x package requires the removal of another. My aim is for these packages to never have to be deinstalled in order to switch the gcc4x in use for a particular package build. -- ___ 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] gcc4x/gcc4x-compiler packages
On 27 Apr 2010, at 17:43, Jack Howarth wrote: To recap, the problem with using a single package with split-off strategy is that both gcc4x and gcc4x-bin would require a Conflicts/ Replaces on the older gcc4x packages which have overlapping files. This is because the older gcc4x packages can't know that they are are able co-exist with the newer gcc4x package and will Conflict with it. This causes dependency failures for fink in the absence of an explicit Jack _ I told you since the beginning (Re: co-existing gcc4x packages, april 25) that it would be much simpler to keep the name gcc45 for the splitoff containing the symlinks _ This way, no need to bother other pkgs, and you avoid the trouble you mention.. Jean-Francois -- ___ 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] gcc4x/gcc4x-compiler packages
On Tue, Apr 27, 2010 at 05:57:11PM +0200, Jean-François Mertens wrote: On 27 Apr 2010, at 17:43, Jack Howarth wrote: To recap, the problem with using a single package with split-off strategy is that both gcc4x and gcc4x-bin would require a Conflicts/ Replaces on the older gcc4x packages which have overlapping files. This is because the older gcc4x packages can't know that they are are able co-exist with the newer gcc4x package and will Conflict with it. This causes dependency failures for fink in the absence of an explicit Jack _ I told you since the beginning (Re: co-existing gcc4x packages, april 25) that it would be much simpler to keep the name gcc45 for the splitoff containing the symlinks _ This way, no need to bother other pkgs, and you avoid the trouble you mention.. Jean-Francois JF, Isn't that going to be considered a massive violation of fink policy for shared library packages? It's sort of like using update-alternatives for manpages and info files. It can be done but many here will find it more repulsive than having package maintainers update the BuildDepends. Frankly, if it came down to it, I would much rather start the new overlapping gcc4x packages with gcc45 than hack up gcc4x by suctioning all of the files out of the main package. Jack -- ___ 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] gcc4x/gcc4x-compiler packages
On 27 Apr 2010, at 18:07, Jack Howarth wrote: On Tue, Apr 27, 2010 at 05:57:11PM +0200, Jean-François Mertens wrote: On 27 Apr 2010, at 17:43, Jack Howarth wrote: To recap, the problem with using a single package with split-off strategy is that both gcc4x and gcc4x-bin would require a Conflicts/ Replaces on the older gcc4x packages which have overlapping files. This is because the older gcc4x packages can't know that they are are able co-exist with the newer gcc4x package and will Conflict with it. This causes dependency failures for fink in the absence of an explicit Jack _ I told you since the beginning (Re: co-existing gcc4x packages, april 25) that it would be much simpler to keep the name gcc45 for the splitoff containing the symlinks _ This way, no need to bother other pkgs, and you avoid the trouble you mention.. Jean-Francois JF, Isn't that going to be considered a massive violation of fink policy for shared library packages? I don't see why.. It's sort of like using update-alternatives for manpages and info files. ??? It can be done but many here will find it more repulsive than having package maintainers update the BuildDepends. Again, I don't see why .. JF -- ___ 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] gcc4x/gcc4x-compiler packages
On Tue, Apr 27, 2010 at 06:20:41PM +0200, Jean-François Mertens wrote: On 27 Apr 2010, at 18:07, Jack Howarth wrote: On Tue, Apr 27, 2010 at 05:57:11PM +0200, Jean-François Mertens wrote: On 27 Apr 2010, at 17:43, Jack Howarth wrote: To recap, the problem with using a single package with split-off strategy is that both gcc4x and gcc4x-bin would require a Conflicts/ Replaces on the older gcc4x packages which have overlapping files. This is because the older gcc4x packages can't know that they are are able co-exist with the newer gcc4x package and will Conflict with it. This causes dependency failures for fink in the absence of an explicit Jack _ I told you since the beginning (Re: co-existing gcc4x packages, april 25) that it would be much simpler to keep the name gcc45 for the splitoff containing the symlinks _ This way, no need to bother other pkgs, and you avoid the trouble you mention.. Jean-Francois JF, Isn't that going to be considered a massive violation of fink policy for shared library packages? I don't see why.. It's sort of like using update-alternatives for manpages and info files. http://www.mail-archive.com/fink-devel@lists.sourceforge.net/msg19967.html ??? It can be done but many here will find it more repulsive than having package maintainers update the BuildDepends. Again, I don't see why .. http://www.finkproject.org/doc/packaging/policy.php?phpLang=en#sharedlibs The approach you describe has never been implemented before and I wouldn't want to be the first unless the core maintainers were okay with it. Bascially, I would have to have... SplitOff: Package: %N-bin Files: bin lib share If folks like Daniel Macks and Martin Costabel are okay with such a radical departure from the usual file distribution in fink packages, I can certainly rewrite the proposed packaging in that manner. Jack ps It is still unclear to me how one would manage to remove the overlapping files from %N-bin but recreate them in %N. I assume I would have to use PostInstScripts in both %N and %N-bin. One to add the overlapping files as symlinks in %N and another to remove the overlapping files from %N-bin. How exactly do I keep these from running into each other (ie %N removing the overlapping files that %N-bin creates). The whole approach just feels hackish to me. JF -- ___ 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] gcc4x/gcc4x-compiler packages
On Tue, Apr 27, 2010 at 05:57:11PM +0200, Jean-Fran?ois Mertens wrote: On 27 Apr 2010, at 17:43, Jack Howarth wrote: To recap, the problem with using a single package with split-off strategy is that both gcc4x and gcc4x-bin would require a Conflicts/ Replaces on the older gcc4x packages which have overlapping files. This is because the older gcc4x packages can't know that they are are able co-exist with the newer gcc4x package and will Conflict with it. This causes dependency failures for fink in the absence of an explicit Jack _ I told you since the beginning (Re: co-existing gcc4x packages, april 25) that it would be much simpler to keep the name gcc45 for the splitoff containing the symlinks _ This way, no need to bother other pkgs, and you avoid the trouble you mention.. That is the same layout/solution I was suggesting, which I think Jack read backwards from the way I tried to describe. For example: Currently: gcc4x: Conflicts/Replaces all other gcc4x Depends: gcc4x-shlibs contents: compiler in lib/gcc4.x/ *1 info/manpages in share/ *1 symlinks from bin/ to lib/gcc4.x/ *2 splitoff:gcc4x-shlibs *1 are the generic-name/collisions among different gcc4x that prevent concurrent installation. It's the default compiler in the standard visible location. *2 are the actual compilers, in a subdir that is specific/named for each different gcc4x package I and I think jfm are suggesting moving *2 into a new package. gcc4x: Conflicts/Replaces all other gcc4x Depends: gcc4x-compiler contents: compiler in lib/gcc4.x *1 info/manpages in share *1 splitoff:gcc4x-compiler Replaces: gcc4x *3 Depends: gcc4x-shlibs contents: symlinks in bin to lib/gcc4.x splitoff:gcc4x-shlibs *3 is so that user can upgrade cleanly from the old gcc4x package...allows new package to overwrite same-named files in old package that are now supposed to be in new/different package. Packages that currently have a dependency on gcc4x and rely on that to supply a compiler in bin/ (i.e., the default PATH), well, that's still true. And the manpages and texinfo files that are in the default doc sets are in that same package. All the default stuff is a self-consistent set in a single package. Obviously you can't default to more than one gcc4x at a time... But now, all the gcc4x-compiler packages are the actual compilers, and because they are each in their own subdir in lib/, they can all be installed concurrently. If a package really wants to, it can access them there (adjusting its PATH or using absolute pathname to ignore the default PATH and therefore not caring what gcc4x default package--if any--is installed). dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- ___ 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] gcc4x/gcc4x-compiler packages
On 27 Apr 2010, at 18:50, Jack Howarth wrote: Bascially, I would have to have... SplitOff: Package: %N-bin Files: bin No bin ; this the point : bin contains only symlinks, which go into gcc45 lib share JF -- ___ 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] gcc4x/gcc4x-compiler packages
On Tue, Apr 27, 2010 at 12:50:43PM -0400, Jack Howarth wrote: On Tue, Apr 27, 2010 at 06:20:41PM +0200, Jean-Fran?ois Mertens wrote: On 27 Apr 2010, at 18:07, Jack Howarth wrote: On Tue, Apr 27, 2010 at 05:57:11PM +0200, Jean-Fran?ois Mertens wrote: On 27 Apr 2010, at 17:43, Jack Howarth wrote: To recap, the problem with using a single package with split-off strategy is that both gcc4x and gcc4x-bin would require a Conflicts/ Replaces on the older gcc4x packages which have overlapping files. This is because the older gcc4x packages can't know that they are are able co-exist with the newer gcc4x package and will Conflict with it. This causes dependency failures for fink in the absence of an explicit Jack _ I told you since the beginning (Re: co-existing gcc4x packages, april 25) that it would be much simpler to keep the name gcc45 for the splitoff containing the symlinks _ This way, no need to bother other pkgs, and you avoid the trouble you mention.. Jean-Francois JF, Isn't that going to be considered a massive violation of fink policy for shared library packages? I don't see why.. It's sort of like using update-alternatives for manpages and info files. http://www.mail-archive.com/fink-devel@lists.sourceforge.net/msg19967.html ??? It can be done but many here will find it more repulsive than having package maintainers update the BuildDepends. Again, I don't see why .. http://www.finkproject.org/doc/packaging/policy.php?phpLang=en#sharedlibs The approach you describe has never been implemented before and I wouldn't want to be the first unless the core maintainers were okay with it. It's approximately how perl is set up. We have perlXXX as the mutually-exclusive (generic filenames in default locations) package, with perlXXX-core as the concurrently-installable (files or directories named specifically for the XXX) back-end. Other packages that are specific to a certain perl version have a dependency on the perlXXX-core they want and access it as (for example) bin/perlX.X.X. A package that would really need bin/perl, as a certain perl version would have a dependency on perlXXX itself. (other concerns snipped, some addressed others in agreement per my other email a few minute ago--things are laggy here:(. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- ___ 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] gcc4x/gcc4x-compiler packages
JF,
Okay. Untested gcc45-x86_64.info with a gcc45-compiler
splitoff. Still needs the libffi update-alternatives.
Jack
Info2:
Package: gcc45
Version: 4.5.0
Revision: 1001
Source: ftp://gcc.gnu.org/pub/gcc/releases/gcc-%v/gcc-%v.tar.bz2
Source-MD5: ff27b7c4a5d5060c8a8543a44abca31f
Source2: ftp://sourceware.org/pub/java/ecj-latest.jar
Source2-MD5: fd299f26c02268878b5d6c0e86f57c43
PatchFile: %n.patch
PatchFile-MD5: 8f46507fc8892e65cb23d0097bcd791d
Distribution: 10.5, 10.6
Type: -64bit .
Architecture: x86_64
NoSetCPPFLAGS: True
NoSetLDFLAGS: True
Conflicts: gcc42, gcc43, gcc44, gcc46
Replaces: gcc42, gcc43, gcc44, gcc46
Depends: gmp-shlibs (= 4.3.1-1000), libgmpxx-shlibs (= 4.3.1-1000),
libmpfr1-shlibs (= 2.4.1-1), %N-compiler (= %v-%r), libiconv,
libgettext8-shlibs, ppl-shlibs (= 0.10.2-1), cloog-shlibs (= 0.15.9-1),
libmpc2-shlibs (= 0.8-1), xcode (= 3.1.2)
BuildDepends: gmp (= 4.3.1-1000), libmpfr1 (= 2.4.1-1), libiconv-dev,
gettext-tools, libgettext8-dev, ppl (= 0.10.2-1), cloog (= 0.15.9-1), libmpc2
(= 0.8-1), xcode (= 3.1.2), fink (= 0.27.2)
ConfigureParams:
--prefix=%p/lib/gcc4.5 --mandir=%p/share/man --infodir=%p/share/info
--enable-languages=c,c++,fortran,objc,obj-c++,java \
--with-gmp=%p --with-libiconv-prefix=%p --with-ppl=%p --with-cloog=%p
--with-mpc=%p --with-system-zlib \
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--program-suffix=-fsf-4.5
CompileScript:
#!/bin/bash -ev
set +x
if [ -e /usr/local/lib/libgmp.a ] || [ -e /usr/local/lib/libgmp.dylib ]; then
echo -WARNING-WARNING-WARNING-
echo You seem to have GMP installed in /usr/local.
echo This is known to cause %N to fail to build.
echo Please move aside /usr/local and try again.
echo -WARNING-WARNING-WARNING-
exit 1
fi
set -x
ulimit -s `ulimit -s`
mv ../ecj-latest.jar ecj.jar
mkdir ../darwin_objdir
cd ../darwin_objdir
../gcc-%v/configure %c
num_cpu=$(echo `sysctl -n hw.ncpu`)
make -j $num_cpu
## make check requires autogen, dejagnu and expect, and should be run, in
darwin_objdir, after install.
## on 32-bit processors use
# make -k check
## on 64-bit processors use
# make -k check RUNTESTFLAGS=--target_board=unix'{-m32,-m64}'
InstallScript:
#!/bin/sh -ev
darwinvers=`uname -r`
cd ../darwin_objdir
make install DESTDIR=%d
mkdir -p %i/bin
# Add symlinks to recreate previous naming of executables
# in %p/lib/gcc4.5/bin and new -fsf-4.5 naming in %p/bin.
binfiles=gcc g++ c++ cpp gcov
for binfile in $binfiles ; do
ln -s %p/lib/gcc4.5/bin/$binfile-fsf-4.5 %i/lib/gcc4.5/bin/$binfile-4
ln -s %p/lib/gcc4.5/bin/$binfile-fsf-4.5 %i/bin/$binfile-4
ln -s %p/lib/gcc4.5/bin/$binfile-fsf-4.5 %i/bin/$binfile-fsf-4.5
done
binfiles=gfortran gcj gcj-dbtool gcjh gij gjnih grmiregistry grmic jcf-dump
jv-convert jv-scan
for binfile in $binfiles ; do
ln -s %p/lib/gcc4.5/bin/$binfile-fsf-4.5 %i/lib/gcc4.5/bin/$binfile
ln -s %p/lib/gcc4.5/bin/$binfile-fsf-4.5 %i/bin/$binfile
ln -s %p/lib/gcc4.5/bin/$binfile-fsf-4.5 %i/bin/$binfile-fsf-4.5
done
# Add symlinks for manpages under old names.
man1files=cpp g++ gcc gcov
for man1file in $man1files ; do
ln -s %p/share/man/man1/$man1file-fsf-4.5.1 %i/share/man/man1/$man1file-4.1
done
man1files=aot-compile gappletviewer gc-analyze gcj-dbtool gcj gcjh gfortran
gij gjar gjarsigner gjavah gjdoc gkeytool gnative2ascii gorbd grmic grmid
grmiregistry gserialver gtnameserv jcf-dump jv-convert rebuild-gcj-db
for man1file in $man1files ; do
ln -s %p/share/man/man1/$man1file-fsf-4.5.1 %i/share/man/man1/$man1file.1
done
man3files=ffi ffi_call ffi_prep_cif
for man3file in $man3files ; do
ln -s %p/man/man3/$man3file-fsf-4.5.3 %i/share/man/man3/$man3file.3
done
# Rename manpages with -fsf-4.5 suffix and create symlinks to old names.
man7files=fsf-funding gfdl gpl
for man7file in $man7files ; do
mv %i/share/man/man7/$man7file.7 %i/share/man/man7/$man7file-fsf-4.5.7
ln -s %p/share/man/man7/$man7file-fsf-4.5.7 %i/share/man/man7/$man7file.7
done
# Rename info files with -fsf-4.5 suffix.
infofiles=cp-tools cpp cppinternals gcc gccinstall gccint gcj gfortran
libgomp
for infofile in $infofiles ; do
mv %i/share/info/$infofile.info %i/share/info/$infofile-fsf-4.5.info
done
# Add symlinks for info files under old names.
infofiles=cpp gcc
for infofile in $infofiles ; do
ln -s %p/share/info/$infofile-fsf-4.5.info %i/share/info/$infofile-4.info
done
infofiles=cp-tools cppinternals gccinstall gccint gcj gfortran libgomp
for infofile in $infofiles ; do
ln -s %p/share/info/$infofile-fsf-4.5.info %i/share/info/$infofile.info
done
cp %b/gcc/config/darwin-sections.def
%i/lib/gcc4.5/lib/gcc/%m-apple-darwin${darwinvers}/%v/plugin/include/config
# remove build path from .la files
perl -pi -e s, \-L[^ ']*/%n-%v-%r/darwin_objdir/[^ ']*,,g `find
%i/lib/gcc4.5/lib -name '*.la'`
SplitOff:
Package: %N-shlibs
Replaces: gcc4 (=
Re: [Fink-devel] gcc4x/gcc4x-compiler packages
Jack Howarth wrote: JF, Okay. Untested gcc45-x86_64.info with a gcc45-compiler splitoff. Still needs the libffi update-alternatives. To me, this one looks OK (untested, of course), contrary to the description in one of dmacks' latest messages (the one with *1, *2 etc), which even after reading it 3 times still looks really backwards. -- Martin -- ___ 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] gcc4x/gcc4x-compiler packages
On Tue, Apr 27, 2010 at 10:40:35PM +0200, Martin Costabel wrote: Jack Howarth wrote: JF, Okay. Untested gcc45-x86_64.info with a gcc45-compiler splitoff. Still needs the libffi update-alternatives. To me, this one looks OK (untested, of course), contrary to the description in one of dmacks' latest messages (the one with *1, *2 etc), which even after reading it 3 times still looks really backwards. Crapola yeah, cut'n'pasted the wrong line! compiler in lib/gcc4.x *1 is what should have gone in gcc4x-compiler. Glad the convoluted explanation was clear enough that at least the other screwup was noticed:( dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- ___ 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] gcc4x/gcc4x-compiler packages
On Tue, Apr 27, 2010 at 03:35:06PM -0400, Jack Howarth wrote: # Rename info files with -fsf-4.5 suffix. # Add symlinks for info files under old names. SplitOff2: Package: %N-compiler Files: share/info/*-fsf-4.5.info InfoDocs: cp-tools-fsf-4.5.info cpp-fsf-4.5.info cppinternals-fsf-4.5.info gcc-fsf-4.5.info gccinstall-fsf-4.5.info gccint-fsf-4.5.info gcj-fsf-4.5.info gfortran-fsf-4.5.info libgomp-fsf-4.5.info I'm not sure there is a use in having *-fsf-4.5.info files. They are not indexed and generally visible unless the gcc4x package is installed (InfoDocs entries). And although they can be accessed if you know their special name, they contain hyperlinks to each other that do not know about these special names (for example, a link in gcj-fsf-4.5 for gcc likely points to gcc not gcc-fsf-4.5). Instead, you could put all the files *with their original filenames* (so xref's don't break) in a directory named for the package. For example, %p/lib/gcc4.5/info (living in the -compilers splitoff package). The xrefs would resolve self-consistently among this specific gcc version because they are pointing to the correct filename in the same directory. Bonus: you can just change --infodir= instead of having to do a manual loop over all the filenames to move them. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- ___ 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] gcc4x/gcc4x-compiler packages
On Tue, Apr 27, 2010 at 11:00:11PM -0400, Daniel Macks wrote: On Tue, Apr 27, 2010 at 03:35:06PM -0400, Jack Howarth wrote: # Rename info files with -fsf-4.5 suffix. # Add symlinks for info files under old names. SplitOff2: Package: %N-compiler Files: share/info/*-fsf-4.5.info InfoDocs: cp-tools-fsf-4.5.info cpp-fsf-4.5.info cppinternals-fsf-4.5.info gcc-fsf-4.5.info gccinstall-fsf-4.5.info gccint-fsf-4.5.info gcj-fsf-4.5.info gfortran-fsf-4.5.info libgomp-fsf-4.5.info I'm not sure there is a use in having *-fsf-4.5.info files. They are not indexed and generally visible unless the gcc4x package is installed (InfoDocs entries). And although they can be accessed if you know their special name, they contain hyperlinks to each other that do not know about these special names (for example, a link in gcj-fsf-4.5 for gcc likely points to gcc not gcc-fsf-4.5). Instead, you could put all the files *with their original filenames* (so xref's don't break) in a directory named for the package. For example, %p/lib/gcc4.5/info (living in the -compilers splitoff package). The xrefs would resolve self-consistently among this specific gcc version because they are pointing to the correct filename in the same directory. Bonus: you can just change --infodir= instead of having to do a manual loop over all the filenames to move them. Bonuser: two fewer places you have to enumerate actual filenames (fewer things to deal with manually). --infodir means you omit this: # Rename info files with -fsf-4.5 suffix. and this: # Add symlinks for info files under old names. infofiles=cpp gcc for infofile in $infofiles ; do ln -s %p/share/info/$infofile-fsf-4.5.info %i/share/info/$infofile-4.info done infofiles=cp-tools cppinternals gccinstall gccint gcj gfortran libgomp for infofile in $infofiles ; do ln -s %p/share/info/$infofile-fsf-4.5.info %i/share/info/$infofile.info done becomes something like this: # Add symlinks for info files under old location. mkdir %i/share/info for infofile in `cd %i/lib/gcc4.5/info; ls`; do ln -s %p/lib/gcc4.5/info/$infofile %i/share/info/$infofile done dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- ___ 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] gcc4x/gcc4x-compiler packages
Daniel, I noticed that when --program-suffix=-fsf-4.5 is invoked that the man1 and man3 manpage names are automatically appended with the -fsf-4.5 suffix but not the info pages. I figured this was an omission so I completed the renaming for man7 and the info pages. Also, now that multiple gcc4x-compiler packages can co-exist, won't it be confusing if each has the same info file names (without a -fsf-4.x suffix)? In that case, how would the user be sure that that correct copy of gcc-4.info which they are being shown is the one from the particular version of gcc that they are trying to work with. With info files having the -fsf-4.x suffix there can be no such confusion. Jack ps In particular, say the user needs a gcc 4.5 info page to read about the LTO options. We need to make certain that the correct one can be easily selected. -- ___ 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] gcc4x/gcc4x-compiler packages
On Wed, Apr 28, 2010 at 12:51:36AM -0400, Jack Howarth wrote: Daniel, I noticed that when --program-suffix=-fsf-4.5 is invoked that the man1 and man3 manpage names are automatically appended with the -fsf-4.5 suffix but not the info pages. I figured this was an omission so I completed the renaming for man7 and the info pages. Also, now that multiple gcc4x-compiler packages can co-exist, won't it be confusing if each has the same info file names (without a -fsf-4.x suffix)? In that case, how would the user be sure that that correct copy of gcc-4.info which they are being shown is the one from the particular version of gcc that they are trying to work with. With info files having the -fsf-4.x suffix there can be no such confusion. Jack ps In particular, say the user needs a gcc 4.5 info page to read about the LTO options. We need to make certain that the correct one can be easily selected. 'info /sw/lib/gcc4.5/info/gcc' or some similar command. Just like he would need 'info /sw/share/info/gcc-fsf-4.5'. I didn't change the unversioned names (symlinks) in /sw/share/info, so installing the gcc4.5 package (which contains them) would still allow 'info gcc' to give the self-consistent ones for gcc4.5. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- ___ 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] gcc4x/gcc4x-compiler packages
I've posted test packaging for a gcc45-4.5.0-1001 and gcc45-compiler-4.5-1 package on fink tracking... https://sourceforge.net/tracker/?func=detailaid=2992713group_id=17203atid=414256 The new gcc45 packaging... 1) Moves all of the currently conflicting files between the gcc4x packages into a new gcc4x-compiler package which recreates them with symlinks. 2) Builds the compiler programs with the -fsf-4.x suffix and presents these program names in %p/bin via symlinks in the main gcc4x package. 3) Provides all of the original program names in %p/lib/gcc4.x/bin. I've tested this packaging by upgrading from the previous gcc45-4.5.0-1000 proposed packaging. A test gcc46 package of the same type was also used to verify that the gcc45/gcc46 packages properly co-exist and that the two gcc45-compiler/gcc46-compiler packages properly switch the default FSF gcc system compiler in %p/bin as well as the associated man and info pages. Jack ps As soon as the FSF gcc 4.4.4 tarballs are available later this week, I'll add a fink tracking entry for gcc44-4.4.4-1000/gcc44-compiler-4.4-1 packaging as well. Once this packaging enters fink unstable, the existing packages that use gcc44 will have to either 1) change the BuildDepends from gcc44 to gcc44-compiler or 2) pass the explicit path to the compilers in %p/lib/gcc4.4/bin. -- ___ 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
