From: Earnie <ea...@us...> - 2011-12-16 18:44:59
|
Chuck, this is mainly to you, I've set out today do learn to create a mgwport package. I chose libiconv as an example where I note one minor bug with a missing backslash \ for the mgwconf command after setting CFLAGS so that LDFLAGS isn't set. Also, I find that msys-mktemp is required but wasn't installed with the installation of mgwport. I've created a src_install() function src_install() { local f cd ${B} mgwinstall dodir $(__host_prefix)/share/doc/${PN}/${PV} for f in ${S}/COPYING ${S}/COPYING.LIB ${S}/README do cp -a ${f} $(__host_prefix)/share/doc/${PN}/${PV}/ done } but I get cp: target `/tmp/mgwport-reloc-hZJhGN/mingw/share/doc/libfoo/1.0/' is not a directory: No such file or directory cp: target `/tmp/mgwport-reloc-hZJhGN/mingw/share/doc/libfoo/1.0/' is not a directory: No such file or directory cp: target `/tmp/mgwport-reloc-hZJhGN/mingw/share/doc/libfoo/1.0/' is not a directory: No such file or directory So how do I correct the issue? I see the mgwport-reloc-hZJhGN directory in both /tmp and in libfoo-1.0-1/install/tmp. The one in /tmp is empty. -- Earnie -- https://sites.google.com/site/earnieboyd/ |
From: Charles W. <cwi...@us...> - 2011-12-16 19:06:41
|
On 12/16/2011 1:44 PM, Earnie wrote: > I've set out today do learn to create a mgwport package. I chose > libiconv as an example I'm unsure what you mean. Are you using libiconv*.mgwport as a pattern, to develop a different package's mgwport, or are you "re-doing" libiconv itself just to get a better feel for how mgwport works? If the former...then libiconv is a poor choice; it and gettext exercise a special purpose feature of mgwport, developed specifically for the mingw versions of those two packages: the "relocatable" stuff. No other package includes Bruno Haible's magic relocate machinery, so attempting to support it (in a .mgwport) for a package that doesn't actually HAVE it is...ill-advised. I'd use mingw32-xz.mgwport as an example, instead. > where I note one minor bug with a missing > backslash \ for the mgwconf command after setting CFLAGS so that LDFLAGS > isn't set. Oh, you're right. That means the currently-shipping libiconv is built with the default -*-libgcc linkage rather than explicitly -shared-libgcc. But -static- is only the default for "C", all other languages default to -shared-. Now, libiconv is written in C -- but the final link is done using C++ (this is part of Bruno's relocation magic) so I don't think this error has any real effect. > Also, I find that msys-mktemp is required but wasn't installed with the > installation of mgwport. Well, it's only required if your .mgwport does 'inherit relocatable' which only mingw-libiconv and mingw-gettext should. > I've created a src_install() function > > src_install() { > local f > cd ${B} > mgwinstall > dodir $(__host_prefix)/share/doc/${PN}/${PV} > for f in ${S}/COPYING ${S}/COPYING.LIB ${S}/README > do > cp -a ${f} $(__host_prefix)/share/doc/${PN}/${PV}/ > done > } > > but I get > > cp: target `/tmp/mgwport-reloc-hZJhGN/mingw/share/doc/libfoo/1.0/' is > not a directory: No such file or directory > cp: target `/tmp/mgwport-reloc-hZJhGN/mingw/share/doc/libfoo/1.0/' is > not a directory: No such file or directory > cp: target `/tmp/mgwport-reloc-hZJhGN/mingw/share/doc/libfoo/1.0/' is > not a directory: No such file or directory > > So how do I correct the issue? I could explain -- but it's unnecessary; the problem is because you're using 'inherit relocatable' when you shouldn't. Remove that and try again. BTW, after you do THAT, then you don't need this either: > dodir $(__host_prefix)/share/doc/${PN}/${PV} > for f in ${S}/COPYING ${S}/COPYING.LIB ${S}/README > do > cp -a ${f} $(__host_prefix)/share/doc/${PN}/${PV}/ > done If you have some files in ${S} that you want installed into docdir, all you need to do is add then to the "DOCS" variable: DOCS="foo doc/bar doc/*html" somewhere in your .mgwport, and mgwport will handle it automatically. However, in this case you don't even need to do that, because mgwport *automatically* installs "README" and "COPYING*" from ${S} into docdir. local default_docs="\ ANNOUNCE ANNOUNCEMENTS AUTHOR AUTHORS \ BUG-REPORTS BUGS \ CHANGES Changes ChangeLog CONTRIBUTORS COPYING COPYING-DOCS COPYING.LIB COPYRIGHT CREDITS \ FAQ GPL HACKING HISTORY HOW-TO-CONTRIBUTE KNOWNBUG \ LEGAL LICENCE LICENSE MAINTAINERS NEWS NOTES NOTICE \ PROGLIST README THANKS TODO WHATSNEW"; -- Chuck |
From: Earnie <ea...@us...> - 2011-12-16 20:39:49
Attachments:
libfoo-1.0-1.mgwport.txt
|
Charles Wilson wrote: > On 12/16/2011 1:44 PM, Earnie wrote: >> I've set out today do learn to create a mgwport package. I chose >> libiconv as an example > > I'm unsure what you mean. Are you using libiconv*.mgwport as a pattern, > to develop a different package's mgwport, Yes > or are you "re-doing" libiconv > itself just to get a better feel for how mgwport works? > No > If the former...then libiconv is a poor choice; it and gettext exercise > a special purpose feature of mgwport, developed specifically for the > mingw versions of those two packages: the "relocatable" stuff. No other > package includes Bruno Haible's magic relocate machinery, so attempting > to support it (in a .mgwport) for a package that doesn't actually HAVE > it is...ill-advised. > > I'd use mingw32-xz.mgwport as an example, instead. > Ok I'll look at xz. >> where I note one minor bug with a missing >> backslash \ for the mgwconf command after setting CFLAGS so that LDFLAGS >> isn't set. > > Oh, you're right. That means the currently-shipping libiconv is built > with the default -*-libgcc linkage rather than explicitly > -shared-libgcc. But -static- is only the default for "C", all other > languages default to -shared-. Now, libiconv is written in C -- but the > final link is done using C++ (this is part of Bruno's relocation magic) > so I don't think this error has any real effect. > Ack. >> Also, I find that msys-mktemp is required but wasn't installed with the >> installation of mgwport. > > Well, it's only required if your .mgwport does > > 'inherit relocatable' > > which only mingw-libiconv and mingw-gettext should. > Well, brewing beans instead of peas I guess. The mgwport package delivers a script /mingw/lib/mgwport/relocatable.mgwpart that requires it so I see it as a requirement of the package. >> I've created a src_install() function >> >> src_install() { >> local f >> cd ${B} >> mgwinstall >> dodir $(__host_prefix)/share/doc/${PN}/${PV} >> for f in ${S}/COPYING ${S}/COPYING.LIB ${S}/README >> do >> cp -a ${f} $(__host_prefix)/share/doc/${PN}/${PV}/ >> done >> } >> >> but I get >> >> cp: target `/tmp/mgwport-reloc-hZJhGN/mingw/share/doc/libfoo/1.0/' is >> not a directory: No such file or directory >> cp: target `/tmp/mgwport-reloc-hZJhGN/mingw/share/doc/libfoo/1.0/' is >> not a directory: No such file or directory >> cp: target `/tmp/mgwport-reloc-hZJhGN/mingw/share/doc/libfoo/1.0/' is >> not a directory: No such file or directory >> >> So how do I correct the issue? > > I could explain -- but it's unnecessary; the problem is because you're > using 'inherit relocatable' when you shouldn't. Remove that and try again. > Ok, I figured it out anyway; to correct I would use ${D}/$(__host_prefix) but I'll remove the relocatable declaration instead. > BTW, after you do THAT, then you don't need this either: > > > dodir $(__host_prefix)/share/doc/${PN}/${PV} > > for f in ${S}/COPYING ${S}/COPYING.LIB ${S}/README > > do > > cp -a ${f} $(__host_prefix)/share/doc/${PN}/${PV}/ > > done > > If you have some files in ${S} that you want installed into docdir, all > you need to do is add then to the "DOCS" variable: > > DOCS="foo doc/bar doc/*html" > Cool. > somewhere in your .mgwport, and mgwport will handle it automatically. > However, in this case you don't even need to do that, because mgwport > *automatically* installs "README" and "COPYING*" from ${S} into docdir. > > local default_docs="\ > ANNOUNCE ANNOUNCEMENTS AUTHOR AUTHORS \ > BUG-REPORTS BUGS \ > CHANGES Changes ChangeLog CONTRIBUTORS COPYING > COPYING-DOCS COPYING.LIB COPYRIGHT CREDITS \ > FAQ GPL HACKING HISTORY HOW-TO-CONTRIBUTE KNOWNBUG \ > LEGAL LICENCE LICENSE MAINTAINERS NEWS NOTES NOTICE \ > PROGLIST README THANKS TODO WHATSNEW"; > And I just discovered this fact. Also MINGW-PATCHES/libfoo-README is installed by default into share/docs/MinGW. I'm seeing another issue with the compile step. There is an libfoo.asd file and a libfoo.asd.in file. The libfoo.asd file is removed with an "*** Info: Removing libfoo.asd to be regenerated by configure". But then immediately I get an error from ln that it can't find libfoo.asd to create the link in the build directory. *** Info: Removing libfoo.asd to be regenerated by configure ln: creating symbolic link `/usr/src/spud/libfoo-1.0-1-mingw32-src/libfoo-1.0-1/src/libfoo-1.0/libfoo.asd' to `/usr/src/spud/libfoo-1.0-1-mingw32-src/libfoo-1.0-1/build/libfoo.asd': No such file or directory Executing the compile step again works since the libfoo.asd file is already removed. Doing the package step I have PKG_NAMES="${PN} ${PN} ${PN} ${PN} ${PN}" PKG_COMPTYPES="bin dev dll-0 lic doc" PKG_CONTENTS[0]='--exclude=bin/*.dll \ --exclude=bin/libfoo-config \ bin' PKG_CONTENTS[1]='--exclude=bin/*.dll \ --exclude=bin/*.exe \ --exclude=share/doc \ bin \ share \ include \ lib' PKG_CONTENTS[2]='bin/libfoo*.dll' PKG_CONTENTS[3]='share/doc/${PN}/${PV}/COPYING \ share/doc/${PN}/${PV}/COPYING.LIB \ share/doc/${PN}/${PV}/README' PKG_CONTENTS[4]='--exclude=share/doc/${PN}/${PV}/COPYING \ --exclude=share/doc/${PN}/${PV}/COPYING.LIB \ --exclude=share/doc/${PN}/${PV}/README share/doc/${PN}/${PV} \ share/doc/MinGW' The package name is correct but the package contents are pulling from / instead of the libfoo-1.0-1/inst directory. What have I forgotten? I've attached the mgwport file. -- Earnie -- https://sites.google.com/site/earnieboyd/ |
From: Earnie <ea...@us...> - 2011-12-23 14:01:02
|
Earnie wrote: >>> Also, I find that msys-mktemp is required but wasn't installed with the >>> installation of mgwport. >> >> Well, it's only required if your .mgwport does >> >> 'inherit relocatable' >> >> which only mingw-libiconv and mingw-gettext should. >> > > Well, brewing beans instead of peas I guess. The mgwport package > delivers a script /mingw/lib/mgwport/relocatable.mgwpart that requires > it so I see it as a requirement of the package. > Given the argument for the pthread library I'm going to push more for the addition of msys-mktemp as a required package for mgwport. -- Earnie -- https://sites.google.com/site/earnieboyd/ |
From: Charles W. <cwi...@us...> - 2011-12-16 21:32:57
|
On 12/16/2011 3:39 PM, Earnie wrote: > I'm seeing another issue with the compile step. There is an libfoo.asd > file and a libfoo.asd.in file. The libfoo.asd file is removed with an > "*** Info: Removing libfoo.asd to be regenerated by configure". But > then immediately I get an error from ln that it can't find libfoo.asd to > create the link in the build directory. > > *** Info: Removing libfoo.asd to be regenerated by configure > ln: creating symbolic link > `/usr/src/spud/libfoo-1.0-1-mingw32-src/libfoo-1.0-1/src/libfoo-1.0/libfoo.asd' > to > `/usr/src/spud/libfoo-1.0-1-mingw32-src/libfoo-1.0-1/build/libfoo.asd': > No such file or directory Hm. What's going on is this: mgwport can tell that libfoo.asd is created by configure, so it takes steps to ensure that the one that WILL be used is actually the new one that configure will (soon) create. The ln part is an attempt to create a dangling symlink first, so that you will see that same "new" file in both ${S} and in ${B}. Works great on cygwin/cygport. Not so much on msys/mgwport -- since we don't have symbolic links, it defaults to a hardlink. But you can't have dangling hardlinks, so: boom. I'll have to think about what the right thing to do here is. Maybe just avoiding the ln step (and adding the deleted file to the list of files to be ignored when creating the .src.patch). > PKG_NAMES="${PN} ${PN} ${PN} ${PN} ${PN}" > PKG_COMPTYPES="bin dev dll-0 lic doc" > PKG_CONTENTS[0]='--exclude=bin/*.dll \ > --exclude=bin/libfoo-config \ > bin' > PKG_CONTENTS[1]='--exclude=bin/*.dll \ > --exclude=bin/*.exe \ > --exclude=share/doc \ > bin \ > share \ > include \ > lib' > PKG_CONTENTS[2]='bin/libfoo*.dll' > PKG_CONTENTS[3]='share/doc/${PN}/${PV}/COPYING \ > share/doc/${PN}/${PV}/COPYING.LIB \ > share/doc/${PN}/${PV}/README' You need to use double quotes here, so that ${PN} and ${PV} can be replaced. > PKG_CONTENTS[4]='--exclude=share/doc/${PN}/${PV}/COPYING \ > --exclude=share/doc/${PN}/${PV}/COPYING.LIB \ > --exclude=share/doc/${PN}/${PV}/README > share/doc/${PN}/${PV} \ > share/doc/MinGW' Ditto. > The package name is correct That's hard to figure since PN is derived from the filename of the .mgwport -- and "foo" != "gpg-error"! > but the package contents are pulling from / > instead of the libfoo-1.0-1/inst directory. What have I forgotten? Doesn't look like you're doing anything wrong. I'll have to try to build the mgwport myself, but I can't do that right now. > I've attached the mgwport file. I've found that libgpg-error on mingw needs: export CPPFLAGS+=" -D__USE_MINGW_ANSI_STDIO -D__USE_MINGW_ACCESS" (doing it this way rather than the "EXTRA_CPPFLAGS" way doesn't let configure "know" about it, but it seems to work). Also, you might want to --disable-nls --disable-languages but that's up to you. -- Chuck |
From: Earnie <ea...@us...> - 2011-12-16 22:12:27
|
Charles Wilson wrote: >> PKG_NAMES="${PN} ${PN} ${PN} ${PN} ${PN}" >> PKG_COMPTYPES="bin dev dll-0 lic doc" >> PKG_CONTENTS[0]='--exclude=bin/*.dll \ >> --exclude=bin/libfoo-config \ >> bin' >> PKG_CONTENTS[1]='--exclude=bin/*.dll \ >> --exclude=bin/*.exe \ >> --exclude=share/doc \ >> bin \ >> share \ >> include \ >> lib' >> PKG_CONTENTS[2]='bin/libfoo*.dll' >> PKG_CONTENTS[3]='share/doc/${PN}/${PV}/COPYING \ >> share/doc/${PN}/${PV}/COPYING.LIB \ >> share/doc/${PN}/${PV}/README' > > You need to use double quotes here, so that ${PN} and ${PV} can be replaced. > Eck, fixed it. >> PKG_CONTENTS[4]='--exclude=share/doc/${PN}/${PV}/COPYING \ >> --exclude=share/doc/${PN}/${PV}/COPYING.LIB \ >> --exclude=share/doc/${PN}/${PV}/README >> share/doc/${PN}/${PV} \ >> share/doc/MinGW' > > Ditto. > >> The package name is correct > > That's hard to figure since PN is derived from the filename of the > .mgwport -- and "foo" != "gpg-error"! > I was trying to be generic and not give away gpg-error as the package name but I missed a data point that gave it away in the attached file. Anyway, it works correctly when PKG_CONTENTS contains the correct data. >> but the package contents are pulling from / >> instead of the libfoo-1.0-1/inst directory. What have I forgotten? > > Doesn't look like you're doing anything wrong. I'll have to try to build > the mgwport myself, but I can't do that right now. > >> I've attached the mgwport file. > > I've found that libgpg-error on mingw needs: > > export CPPFLAGS+=" -D__USE_MINGW_ANSI_STDIO -D__USE_MINGW_ACCESS" > (doing it this way rather than the "EXTRA_CPPFLAGS" way doesn't let > configure "know" about it, but it seems to work). > Hmm, I haven't caught that need yet but I'll check it out. Thanks. > Also, you might want to > --disable-nls > --disable-languages > but that's up to you. > Right. Thanks for the help, -- Earnie -- https://sites.google.com/site/earnieboyd/ |
From: Earnie <ea...@us...> - 2011-12-16 22:33:26
|
Charles Wilson wrote: > On 12/16/2011 3:39 PM, Earnie wrote: >> I'm seeing another issue with the compile step. There is an libfoo.asd >> file and a libfoo.asd.in file. The libfoo.asd file is removed with an >> "*** Info: Removing libfoo.asd to be regenerated by configure". But >> then immediately I get an error from ln that it can't find libfoo.asd to >> create the link in the build directory. >> >> *** Info: Removing libfoo.asd to be regenerated by configure >> ln: creating symbolic link >> `/usr/src/spud/libfoo-1.0-1-mingw32-src/libfoo-1.0-1/src/libfoo-1.0/libfoo.asd' >> to >> `/usr/src/spud/libfoo-1.0-1-mingw32-src/libfoo-1.0-1/build/libfoo.asd': >> No such file or directory > > Hm. What's going on is this: mgwport can tell that libfoo.asd is > created by configure, so it takes steps to ensure that the one that WILL > be used is actually the new one that configure will (soon) create. The > ln part is an attempt to create a dangling symlink first, so that you > will see that same "new" file in both ${S} and in ${B}. > > Works great on cygwin/cygport. > > Not so much on msys/mgwport -- since we don't have symbolic links, it > defaults to a hardlink. But you can't have dangling hardlinks, so: boom. > > I'll have to think about what the right thing to do here is. Maybe just > avoiding the ln step (and adding the deleted file to the list of files > to be ignored when creating the .src.patch). > I think not doing the ln step is correct for both Cygwin/cygport and msys/mgwport. The source directory shouldn't care to have the file, IMNSHO. The other generated from *.in files aren't linked to the source directory. -- Earnie -- https://sites.google.com/site/earnieboyd/ |
From: Charles W. <cwi...@us...> - 2011-12-17 00:53:56
|
On 12/16/2011 5:32 PM, Earnie wrote: >> I'll have to think about what the right thing to do here is. Maybe just >> avoiding the ln step (and adding the deleted file to the list of files >> to be ignored when creating the .src.patch). >> > > I think not doing the ln step is correct for both Cygwin/cygport and > msys/mgwport. The source directory shouldn't care to have the file, > IMNSHO. The other generated from *.in files aren't linked to the source > directory. I think it is to support poorly-written Makefile.in's that (a) include the target (generated) file in another rule's dependency list, but (b) don't properly handle out-of-source and $VPATH builds. See, if a file is generated during configure, then *it shouldn't be shipped in the src tarball*. But, if mgwport had to delete it from ${S}, then somebody DID ship it in the src tarball. So, *something* somewhere in the build system expects that it will appear in the ${S} dir, not the ${B} dir... However, I don't like catering to broken builds (my suggestion would be "fix the package") so... Try the following patch. --- a/mgwclass/autotools.mgwclass +++ b/mgwclass/autotools.mgwclass @@ -484,7 +484,9 @@ mgwconf() { then inform "Removing ${f} to be regenerated by configure" rm -f ${confdir}/${f} - ln -sf ${confdir/${S}/${B}}/${f} ${confdir}/${f} + # also remove from origsrcdir so that .src.patch does + # not erroneously report this as a 'diff'. + rm -f ${confdir/${srcdir}/${origsrcdir}}/${f} fi done As far as cygwin/cygport goes, I have no control over that. I'm still trying to get Yaakov to adopt the latest upstream config.guess/config.sub -- but it's been a month and counting. -- Chuck |
From: Earnie <ea...@us...> - 2011-12-19 16:15:59
|
Charles Wilson wrote: > On 12/16/2011 5:32 PM, Earnie wrote: >>> I'll have to think about what the right thing to do here is. Maybe just >>> avoiding the ln step (and adding the deleted file to the list of files >>> to be ignored when creating the .src.patch). >>> >> >> I think not doing the ln step is correct for both Cygwin/cygport and >> msys/mgwport. The source directory shouldn't care to have the file, >> IMNSHO. The other generated from *.in files aren't linked to the source >> directory. > > I think it is to support poorly-written Makefile.in's that (a) include > the target (generated) file in another rule's dependency list, but (b) > don't properly handle out-of-source and $VPATH builds. > Yea, I tend to build out-of-source but occasionally because of what you've stated need to build in-source which I despise. > See, if a file is generated during configure, then *it shouldn't be > shipped in the src tarball*. But, if mgwport had to delete it from > ${S}, then somebody DID ship it in the src tarball. So, *something* > somewhere in the build system expects that it will appear in the ${S} > dir, not the ${B} dir... However, I don't like catering to broken > builds (my suggestion would be "fix the package") so... > Agree. > Try the following patch. > Works as expected. -- Earnie -- https://sites.google.com/site/earnieboyd/ |