Re: setup.exe cvs -D20011202 dumps core
"Robert Collins" <[EMAIL PROTECTED]> writes: > run cvs update -PdAkkv -rcategories. > [..] > HEAD has a few issues just now :}. Thanks for the info! > Lastly, [EMAIL PROTECTED] is the best list for setup.exe > discussion. (And if you're building from source I suggest you subcribe > to that list). Ok. Just did, because of my new texmf package :-) Greetings, Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
RFP: texmf
Hi List, As announced earlier, I'd like to contribute a set of texmf packages from teTeX that match contrib/tetex-beta. Its previous incarnation received some positive comments already. It's seen some fixes and has even been tested a bit more, find it at http://lilypond.org/people/jan/gnu-windows/tar/texmf There's a setup.ini that delivers the packages [as part of the experimental LilyPond distribution] in the directory: http://lilypond.org/people/jan/gnu-windows where you can point your setup.exe to. Note that tetex-beta may need a rebuild and possibly a dependency on texmf-base; which is beyond my capabilities. Greetings, Jan. (btw, RFP, is that an `I followed through on my ITP'?) -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: RFP: texmf
Christopher Faylor <[EMAIL PROTECTED]> writes: > >Note that tetex-beta may need a rebuild and possibly a dependency on > >texmf-base; which is beyond my capabilities. > > It sounds like this is beyond our capabilities, too. If this is going > to break an existing package then there is no way we can accept it. If you look at it that way, tetex-beta should have been removed a long time ago. It needs a rebuild for certain executables, which has nothing to do with this texmf package. (Texmf is platform independent.) In fact, tetex-beta has been fairly useless (IMHO) because it lacks a texmf tree, that the user was supposed to provide. We've been waiting for a long time for the tetex-beta maintainer to provide the missing texmf package. Now that he said he wasn't planning to provide it at all, I've asked around if a texmf package would be welcomed (and subsequently spent quite some time on it). Note that for most normal use (running tex/latex) it will work fine. Providing a broken package is no use to me. I don't even have a windows machine; this is only for [our] windows users. Greetings, Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: RFP: texmf
Charles Wilson <[EMAIL PROTECTED]> writes: > But, regardless, tetex needs to be rebuilt and I think I remember the > maintainer stating that it WOULD be rebuilt soon. Ah, very good! I must have missed a reply, sorry for the confusion. That's another reason I've provided these packages now: probably tetex-beta (more properly called tetex-bin) needs to know about texmf-base; much easier when a(n experimental) version is available. Greetings, Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: [REQ] apache-1.3.22 package available
"Ralf Habacker" <[EMAIL PROTECTED]> writes: > > > I like httpd most but www is probably easier to remember. > > > > I think /etc/apache is best, so is /var/apache probably best too. > > > I would prefer /etc/httpd as use by (suse) linux, but they have an exception for the >docroot > =/usr/local/httpd In short: everyone likes to have it the way My Currently Favourite Linux Distro (TM) has it. So, because Cygwin is associated with Red Hat, why not standardise on that? (Personally I like /etc/apache, /var/www best, because that's what Debian does :-) Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: RFP: texmf
[EMAIL PROTECTED] (Jerome BENOIT) writes: > I will try to rebuild the tetex-beta package this week-end. > To avoid any confusion, I plan to rename it `tetex-bin' as suggested > in a previous email. Very nice. > So far I can run all the executables on my computer: > please, what you mean by "It needs a rebuild for certain executables" ? Sorry for the vagueness, I only heard some complaints when I sent the message. I've investigated a bit, and pdftex.exe doesn't run when libjpeg isn't installed (this was missing from my texmf requires: line). Also, texconfig doesn't run when libncurses5 is not installed, while the current default is libcurses6? But I really don't know, there were complaints on the list. Looking at it now, it seems to me that both problems would be fixed by adding these to tetex-beta/bin's setup.hint: requires: ash bash cygwin libncurses5 jpeg libpng tiff ncurses sed termcap texmf-base zlib a good idea in any case, but I don't know if there are other problems, or what the idea is with the ncurses5/6 libs. Maybe we should rename texmf-base to tetex-base? Also, if you (or anyone else) would like to take over the texmf packages I did, please do so. But suggestions are welcome too. > `texmf' is of course platform independent execpt for the web2c directory > which is platform dependent ! Yes, but we can define the default layout, and the .fmt get generated during postinstall. It would be good if tetex-bin would do that too, I think? Btw, texmf-base now includes your .frozen config files without the .frozen suffix. Maybe we can do better than that? > > In fact, tetex-beta has been fairly useless (IMHO) because it lacks a > > texmf tree, that the user was supposed to provide. > > So far I can understand, this should not be a big deal for cygwin users. Maybe not. But it would be nice if all packages would `just work' after running setup.exe, which shouldn't be so hard to achieve with tetex? Letting the user handle part of the installation procedure is annoying, requires some knowledge, reading, and a certain level of computer-savvyness, plus it makes installing LilyPond unnecessarily complex. In short: this isn't an option. The biggest problem for windows users involve getting (mik)tex up and running. If you let any room for users to make mistakes, some will, and will complain. > > I've asked around if a texmf package would be welcomed (and > > subsequently spent quite some time on it). > > > Sorry I don't understand the point: > a complete `texmf' (platform independent) package is available on CTAN. Sure, but packaging it for cygwin does require some work. Also, I don't have a windows development box (an oxymoron?), last-week's latest cygwin didn't cross-compile on my own box (fixed with 1.3.6), and handling and transferring these big packages is a bit of a pain. > By "It needs a rebuild for certain executables", > do you mean that cygwin exectables run only on cygwin ? Don't know, let's ask the people that complained about texmf? Greetings, Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: RFP: texmf
Christopher Faylor <[EMAIL PROTECTED]> writes: > On Wed, Dec 05, 2001 at 01:53:51AM +0100, Jan Nieuwenhuizen wrote: > >[EMAIL PROTECTED] (Jerome BENOIT) writes: > >>I will try to rebuild the tetex-beta package this week-end. To avoid > >>any confusion, I plan to rename it `tetex-bin' as suggested in a > >>previous email. > > > >Very nice. > > Actually, I'm not so sure. How is this going to avoid confusion? The old > package will still be around and it will be named 'tetex-beta'. How long would it take to phase them out? A fresh setup.ini that doesn't mention tetex-beta would make tetex-beta invisible? Hmm, but then we'd need a 'conflicts:' setup hint or so, and locally cached setup.ini's could generate trouble. Anyway, the best part is the fact that tetex-beta/bin gets a rebuild, and we're talking. Of course, the renaming should be a bonus, not a pain. > >Maybe we should rename texmf-base to tetex-base? Also, if you (or > >anyone else) would like to take over the texmf packages I did, please > >do so. But suggestions are welcome too. > > If someone will be around to either fix setup.exe to deal with this scenario > or fix the inevitable user questions then renaming sounds like it makes > sense. And it would need some testing too. Phasing-out packages will be a needed feature at some point, but maybe not highest priority now. What about pre/postremove scripts, eg? Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
new cygwin-cross-1.3.6.1
Hi, Some people promised to have a look at my cross build scripts package so I've made some fixes. It should generate fully Cygwin compliant binary and source packages now, I hope. http://lilypond.org/people/jan/gnu-windows/cygwin-cross-1.3.6.1.tar.gz I've also added a small test package 'foo', that shows how these scripts can be used to easily build and package new packages for Cygwin. Greetings, Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: Figlet-2.2 Experimental
Christopher Faylor <[EMAIL PROTECTED]> writes: > > __ _ ___ _ _ _ _(_) |_ > >/ _` / -_) '_| '_| | _| > >\__, \___|_| |_| |_|\__| > >|___/ > > Was there something you wanted to say, here? Just quoting other > people's messages isn't very useful. In this case it was, look at his unusually big signature. 00:28:19 fred@appel:~$ dpkg --status figlet Package: figlet Status: install ok installed Description: Frank, Ian & Glenn's Letters Figlet is a program that creates large characters out of ordinary screen characters. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: experimental texmf packages
Jan Nieuwenhuizen <[EMAIL PROTECTED]> writes:
> > BTW: can you freshed up your postremove patch? I'd like that to be
> > included in setup.
>
> Yes, will do.
cygwin-installer-20011208.ChangeLog
2001-12-08 Jan Nieuwenhuizen <[EMAIL PROTECTED]>
* Makefile.in (CFLAGS): Remove -Werror to allow build.
(realclean): more clean.
* configure.in (LIB_AC_PROG_CXX): Bugfix for CXXFLAGS override.
* desktop.cc (etc_profile): Remove line breaks and spaces from PS1.
* Forward port cygwin-20010707.jcn3.patch.
* postinstall.cc (do_postinstall): Split off:
(init_run_script): New function.
(run_script_in_etc_postinstall): New function.
* package_meta.cc (try_run_script): New function.
(uninstall): Run pre- and postremove scripts.
* install.cc (do_install): Run script initialisation.
cygwin-installer-20011208.patch
diff -purN --exclude=*~ --exclude=configure --exclude=setup_version.c
--exclude=inilex.l --exclude=zlib --exclude=ChangeLog ../cinstall.orig/Makefile.in
./Makefile.in
--- ../cinstall.orig/Makefile.inMon Dec 3 23:22:08 2001
+++ ./Makefile.in Sat Dec 8 15:01:16 2001
@@ -35,7 +35,7 @@ CC:= @CC@
CC_FOR_TARGET := $(CC)
CXX:= @CXX@
-CFLAGS := @CFLAGS@ -Werror -Winline -Wall -Wpointer-arith -Wcast-align\
+CFLAGS := @CFLAGS@ -Winline -Wall -Wpointer-arith -Wcast-align\
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes \
-Wmissing-declarations -Wcomments
CXXFLAGS := @CXXFLAGS@ $(CFLAGS) -fno-rtti
@@ -169,7 +169,8 @@ clean:
$(MAKE) -C zlib clean
realclean: clean
- rm -f Makefile config.cache
+ rm -f Makefile *.d
+ rm -f config.cache config.log config.status
install: all
$(SHELL) $(updir1)/mkinstalldirs $(bindir) $(etcdir)
diff -purN --exclude=*~ --exclude=configure --exclude=setup_version.c
--exclude=inilex.l --exclude=zlib --exclude=ChangeLog ../cinstall.orig/configure.in
./configure.in
--- ../cinstall.orig/configure.in Mon Dec 11 01:07:56 2000
+++ ./configure.in Sat Dec 8 14:19:19 2001
@@ -64,7 +64,7 @@ if test -z "$CXX"; then
test -z "$CC" && AC_MSG_ERROR([no acceptable cc found in \$PATH])
fi
-CXXFLAGS='$(CFLAGS)'
+CXXFLAGS="$CFLAGS"
])
AC_CANONICAL_SYSTEM
diff -purN --exclude=*~ --exclude=configure --exclude=setup_version.c
--exclude=inilex.l --exclude=zlib --exclude=ChangeLog ../cinstall.orig/desktop.cc
./desktop.cc
--- ../cinstall.orig/desktop.cc Thu Nov 29 10:52:32 2001
+++ ./desktop.ccSat Dec 8 14:10:56 2001
@@ -81,9 +81,7 @@ static const char *etc_profile[] = {
"done",
"",
"export MAKE_MODE=unix",
- "export PS1='\\[\\033]0;\\w\\007",
- "\\033[32m\\]\\u@\\h \\[\\033[33m\\w\\033[0m\\]",
- "$ '",
+ "export PS1='\\[\\033]0;\\w\\007\\033[32m\\]\\u@\\h \\[\\033[33m\\w\\033[0m\\]$ '",
"",
"cd \"$HOME\"",
"",
diff -purN --exclude=*~ --exclude=configure --exclude=setup_version.c
--exclude=inilex.l --exclude=zlib --exclude=ChangeLog ../cinstall.orig/install.cc
./install.cc
--- ../cinstall.orig/install.cc Thu Nov 29 10:52:33 2001
+++ ./install.ccSat Dec 8 14:29:13 2001
@@ -53,6 +53,7 @@ static const char *cvsid =
#include "compress_gz.h"
#include "archive.h"
#include "archive_tar.h"
+#include "postinstall.h"
#include "package_db.h"
#include "package_meta.h"
@@ -418,6 +419,9 @@ do_install (HINSTANCE h)
create_mount ("/usr/bin", cygpath ("/bin", 0), istext, issystem);
create_mount ("/usr/lib", cygpath ("/lib", 0), istext, issystem);
set_cygdrive_flags (istext, issystem);
+
+ /* Let's hope people won't uninstall packages before installing [b]ash */
+ init_run_script ();
packagedb db;
for (packagemeta * pkg = db.getfirstpackage (); pkg;
diff -purN --exclude=*~ --exclude=configure --exclude=setup_version.c
--exclude=inilex.l --exclude=zlib --exclude=ChangeLog ../cinstall.orig/package_meta.cc
./package_meta.cc
--- ../cinstall.orig/package_meta.ccSun Dec 2 04:25:11 2001
+++ ./package_meta.cc Sat Dec 8 14:50:12 2001
@@ -37,6 +37,7 @@ static const char *cvsid =
#include "category.h"
+#include "postinstall.h"
#include "package_version.h"
#include "cygpackage.h"
@@ -61,6 +62,15 @@ static const char *standard_dirs[] = {
0
};
+static void
+try_run_script (char const *dir, char const *fname)
+{
+ if (_access (cygpath (dir, fname, ".sh", 0), 0) == 0)
+run_script (dir, concat (fname, ".sh", 0));
+ if (_access (cygpath (dir, fname, ".bat", 0), 0) == 0)
+run_script (dir, concat (fna
broken setup.hint files
Hi, After I added setup.hint support to my gen-ini script, I found that quite some setup.hint files are broken. Most of them could be fixed by doing: hint="$(echo | cat $i/setup.hint - | grep -Ev '^(prev)|(curr|@) ' | sed -e 's/^\(\(category\)\|\(ldesc\)\|\(requires\)\|\(sdesc\)\|\(test\)\). */\1: /' | grep -v '^$')" I found these ncurses jpeg libncurses5 libncurses6 libpng tiff tetex textutils to be broken, it would be nice if these could be replaced in the archive. Automagically fixed versions can be found at http://lilypond.org/gnu-windows/testing Greetings, Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: multiple mirror code && setup HEAD
"Robert Collins" <[EMAIL PROTECTED]> writes: > So go nuts on it :]. 00:23:59 fred@appel:/home/cygwin/cygwin-1.3.6/usr/src/cygwin-cvs/src/winsup/cinstall$ make w32api_lib=$CYGWIN/usr/lib/w32api CXX="g++ -L$CYGWIN/usr/lib/mingw"g++ -L/home/fred/usr/src/cygwin/cygwin-1.3.6/usr/lib/mingw -c -mno-cygwin -mno-cygwin -Winline -Wall -Wpointer-arith -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wcomments -fno-rtti ... archive.cc In file included from /home/cygwin/cygwin-1.3.6/usr/src/cygwin-cvs/src/winsup/w32api/include/windows.h:105, from win32.h:26, from archive.cc:24: /home/cygwin/cygwin-1.3.6/usr/src/cygwin-cvs/src/winsup/w32api/include/winbase.h:841: redefinition of `struct _OSVERSIONINFOA' /home/cygwin/cygwin-1.3.6/usr/src/cygwin-cvs/src/winsup/w32api/include/winnt.h:2032: previous definition here Looks like the error is purely in latest cvs headers. Just updated from :pserver:[EMAIL PROTECTED]:/cvs/src Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: multiple mirror code && setup HEAD
"Robert Collins" <[EMAIL PROTECTED]> writes: > (or run cvs update -Pd -D"2 days ago" in the w32api directory :}. Well, I didn't exactly go nuts on it, but it seems to run fine. Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: broken setup.hint files
Charles Wilson <[EMAIL PROTECTED]> writes: > > hint="$(echo | cat $i/setup.hint - | grep -Ev '^(prev)|(curr|@) ' | sed -e >'s/^\(\(category\)\|\(ldesc\)\|\(requires\)\|\(sdesc\)\|\(test\)\). */\1: /' | grep >-v '^$')" > > > Ummm...they are not broken. You just dislike some stylistic choices... Well, setup.exe barfs on the. Quoting from inilex.l: "sdesc:" return SDESC; "ldesc:" return LDESC; "category:" return CATEGORY; "requires:" return REQUIRES; So, after reading this and the setup.hint spec on cygwin.com, I implemented hinting, in gen-ini.sh and it *broke* setup.exe. So, I considered it a bug, and wanted you to know about it. But if you don't care, fine. > Also, blindly removing the prev/curr/test markers is not a good thing > either. For me, it's *a lot* better than a barfing setup.exe. > Sometimes (when upset's automatic version parser fails) Who is `upset'? I haven't seen my version parser fail, but in general one should not provide the same information from two sources. Which do you trust when they do not match? Why not just have a sane archive, or fix setup.ini by hand if you don't like it? If a version parser fails, the offending package (filename) should be fixed, imo. > the hints may just be old. Yes, I guess that they're old. If old things don't get fixed, the get bitrot. > In my case, I will update a given setup.hint to follow that new > *recommendation* (not requirement) the next time I update the package > controlled by it, and not until then. Indeed, parts of the cygwin archive are a bit of a mess, but it's too bad if it's by principle, and not for want of time. > If it ain't broken (and it ain't) then don't fix it. Well, sorry to bother you then. I can keep kludging around this small thing too. Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: Removed many older packages from contrib, latest yesterday
Christopher Faylor <[EMAIL PROTECTED]> writes: > Just a heads up that I took a sweep through the contrib and latest > directory yesterday and deleted a number of older packages. Good. Have you got a quick list? > Currently, we have a lot of free disk space on this partition but that > is usually slowly eaten up by the gcc and gdb snapshots. Lo and behold, the texmf packages coming up real soon. I'd better not need too many versions to get them right. :-) Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: broken setup.hint files
Charles Wilson <[EMAIL PROTECTED]> writes: > You are right: the *setup.ini* grammar as parsed by *setup.exe* requires > colons. However, setup.ini is created on sourceware by a script > called "upset". And, the *setup.hint* grammar as parsed by upset > doesn't require colons. Ah, but it does as I parse http://cygwin.com/setup.html. Anyway, it's a lot easier if the syntaxes match! > Ah -- upset is the setup.hint parser that creates setup.ini. You seem > to have written your own setup-ini builder and called it > 'gen-ini.sh'. Yes, I looked around and asked once before but. > I am not going to "fix" my setup.hint files to make your parser happy -- > the only parser I care about is the REAL one, upset. Now that you've sent the code to upset, that seems a lot more reasonable. > Also, us normal cygwin maintainers CANNOT force the upstream > maintainers to use a sane naming scheme (see below). Ok, but cygwin could do some sanatising? Some mainainers don't understand that package names don't have capitals (mysql?) or spaces... > And when upset creates setup.ini, it first uses the filenames of the > archives -- but then setup.hint can be used to OVERRIDE it when > necessary. Ok. > Here's a (real life) example: > openssh-2.9p2-3 (released on Jul 26, 2001) > openssh-2.9.9p2-1 (released on Sep 28, 2001) > > if you sort this using normal (computer) lexical sorting, you end up with: > > prev: openssh-2.9.9p2-1 > curr: openssh-2.9p2-3 Ha, my tarball-sort gets this right: 00:37:22 fred@appel:~/usr/src/cygwin-cross-1.3.6.2$ echo -e 'openssh-2.9p2-3\nopenssh-2.9.9p2-1\nopenssh-1.0' | ./bin/tarball-sort.sh openssh-1.0 openssh-2.9p2-3 openssh-2.9.9p2-1 but I see your point, there are situations > foo-20010531 and not foo-1.3.5 where smart algorithms won't work. Still, I haven't seen that situation in Cygwin, and I'm always looking for thing to do better, smaller or smarter. Thought this was such a little thing too. > the new *recommendation* is to NOT specify curr/prev in setup.hint > and rely on upset's parsing of archive names. [..] If your parser > doesn't work, that's not my problem. Ok. Too bad I didn't have update before. > It's not principle or want of time. AFAICT, there is no mess. I would never have introduced bz2, or if I had, I would surely have run a small script like: gzip -dc $foo.gz | bzip2> $foo.bz2 over the archive. There are now two flavours of -src.tar.* packages. There are quite some packages (patched!) that don't do --srcdir builds anymore. etc. Small things that make `make world' mode hairy. > How about don't "kludge around it" -- try fixing your parser. Sure. But I still think that running a script once, that replaces some spaces with commas, is way better than writing (and carrying along) more (hairy) code... > the precursor to cgf's current upset. Thanks! [Why] isn't this is cvs!? > #!/usr/bin/perl > # -*- perl -*- Ah, not fair, 200 lines of perl, where I only have 100 lines of bash. No wonder my scripts lacks some features. Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: experimental texmf packages
"Robert Collins" <[EMAIL PROTECTED]> writes:
> Follow to cygwin-patches please.
(oops, let's see if I can post there?)
> Thanks for freshening this up. There's still a little more to do, but it
> looks good nonetheless.
Ok. Last status was: discussion document (otherwise it would have
gone in :-)
> > * Makefile.in (CFLAGS): Remove -Werror to allow build.
>
> The Werror is in by design. If your patch won't build with it, I won't
> accept you patch.
Ah, good. But it was not for my patch! The latest cvs setup.exe
won't build without it, in my environment. I get warnings (-> errors)
like:
/home/fred/usr/src/cygwin/cygwin-1.3.6/usr/src/cygwin/src/winsup/w32api/include/rpcndr.h:252:
warning: function declaration isn't a prototype
In file included from
/home/fred/usr/src/cygwin/cygwin-1.3.6/usr/src/cygwin/src/winsup/w32api/include/ole2.h:5,
from
/home/fred/usr/src/cygwin/cygwin-1.3.6/usr/src/cygwin/src/winsup/w32api/include/shlobj.h:8,
from mklink2.c:3:
/home/fred/usr/src/cygwin/cygwin-1.3.6/usr/src/cygwin/src/winsup/w32api/include/objbase.h:165:
warning: function declaration isn't a prototype
/home/fred/usr/src/cygwin/cygwin-1.3.6/usr/src/cygwin/src/winsup/w32api/include/objbase.h:166:
warning: function declaration isn't a prototype
make: *** [mklink2.o] Error 1
> > * configure.in (LIB_AC_PROG_CXX): Bugfix for CXXFLAGS override.
>
> What's wrong with the current method?
At some point, it feeds $(CXXFLAGS) to the shell, which complains that
CXXFLAGS is not a command.
> > * desktop.cc (etc_profile): Remove line breaks and spaces from PS1.
>
> The line is now > 80 chars, and indent will break it up again. Is there
> some reason for this change?
Ah, that's how this bug got in, probably. You may not notice it
because your /etc/profile won't be overwritten, or you have your own
PS1, but the default prompt from unpatched install looks like this:
tineke@DOOS ~
$ logout
Connection to doos closed.
with the fix, it looks like this:
tineke@DOOS ~$ logout
(but we'll have to do another sane line break, because of indent.)
> > * package_meta.cc (try_run_script): New function.
>
> This doesn't belong here. It's nothing to do with the package, but with
> interfacing with the shell/scripts. Also (this one is minor/optional),
> cygpath and _access are deprecated - foo = io_stream::open (concat
> ("cygfile://", dir, fname, 0), "rb") followed by run_script (foo) would
> be the more OO approach here.
>
> In the future I think we'll want a script or shell class to encapsulate
> all of this.
Ok. In short: I tried to update the patch with a minimal amount of
extra/moved code. The comments suggest that pkg managent is still in
flux. I can fix the file exists check, but where do you want the
function to go?
Btw: is someone working on conflicts: or more versatile requires:? I
may want to have a look at adding versioned and/or alternative
requires. It would be easiest to change the syntax to something like:
requires: foo, bar | baz >= 1.3, bla
Would that be feasible, or will the space as separator stay, and must
we go for something like:
requires: foo bar|baz>=1.3 bla
It's a quite small patch, if the functionality is ok, I guess I/we can
fix these details?
> You're missing postinstall.h in your changelog.
Ok.
> Also postinstall.h won't compile if it's the only include
Ok.
Greetings,
Jan.
--
Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: broken setup.hint files
Charles Wilson <[EMAIL PROTECTED]> writes: > should have asked Chris for > permission to post his code > [] > Because it is completely and totally unsupported [..] > not enough (global) benefit. Therefore: unsupported and not > widely available. I can understand the `unsupported' part very well, because, well, it's got to do some hairy things. But the `not widely available' is a bit of a shame; what's the use in me writing my own gen-ini, and then eating your time with complaints like these messages? > No.(*) "Is foo-09 the same as foo-9?" "Yes, we renamed it so that it > would sort properly against foo-10." "That was dumb". Ok. > some people care about bandwidth. [..] > Oh boy. That would REALLY screw up setup. See robert's message. Ok, but increasing the release version while doing this would have been easy too. > > There are now two flavours of -src.tar.* packages. > > later there will be even more. [..] > Take those issues up with the maintainer of the specific package you are > concerned about. Provide patches to enable that package to build Ok, but you asked to clarify what I considered to be messy, so that's what I did. I'm the one who get stung by it, most people don't yet care about rebuilding [parts of] the archive, yet. > Make world is not a goal. I still think that's strange. Any distro should be able to do make world. It would not be difficult to start this up, and add packages as they get make world compliant. > Until then, we have a two step process...setup.hint --(upset)--> > setup.ini --(setup.exe)--> installation Ok. > Yeah. But you assumed that it was the setup.hints on sourceware that > had a problem Yes, because they don't comply with cygwin.com/setup.html. > -- and went so far as to post "corrected" ones on a public > webserver -- Of course; don't complain without (proposed) fix! > not feature-rich enough. *That's* what rubbed me the wrong way -- > but I am sorry for the rant-ness of my earlier message. Thanks, and me too. I got ranting because I was expecting something like: Ah, good. But you're @&%#$]! to remove prev, curr, test makers; if you do the space/colon replacement too, we'll see if we can update the hint files. (although we don't care too much because upset doesnt get upset, see attchmnt). Greetings, Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: broken setup.hint files
"Robert Collins" <[EMAIL PROTECTED]> writes: > I don't grok this. Take conflicting packages - they do exist - how do > you propose to make world on them? Oh, I didn't introduce the term make world here, but I liked it and thus copied it. [as everyone probably knew by then I was doing cross-builds including packaging, a *bsd make world is not exactly what I do.] What I mean is: all packages should be automagically buildable: fetch, unpack, build, repack. The 'make world' aspect: do that for all packages available, is something that will follow as soon as all packages behave. > I maintain that the ability to automatically make a package from the > commandline is desired, but that that and make world are orthogonal. Ok, just a matter of definition, so it seems. Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: FIGlet (again)
"Ebrey, Carl" <[EMAIL PROTECTED]> writes: > === > Information in this email and any attachments are confidential, and may > not be copied or used by anyone other than the addressee, nor disclosed > to any third party without our permission. Does this mean I'm liable now that I pressed Follow-Up, or was 'the internet' already the addressee, in this case? > There is no intention to > create any legally binding contract or other commitment through the use > of this email. > > Experian Limited (registration number 653331). > Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: tetex-beta-20001218 available for testing
"Jérôme-Georges-Michel BENOIT" <[EMAIL PROTECTED]> writes: > I have just put a new rebuilt of tetex-beta-20001218 > for test. Thanks. Any chance for us earthlings being able download this today? [is there any 'direct mirror?'] > A more mature version will be made out in accordance > with a texmf package. I'll try to get a first texmf package out asap. Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: tetex-beta-20001218 available for testing
"Jérôme-Georges-Michel BENOIT" <[EMAIL PROTECTED]> writes: Hi Jérôme, > I have just put a new rebuilt of tetex-beta-20001218 for test. A > more mature version will be made out in accordance with a texmf > package. Last night, I've rebuild the texmf packages, but I found that you removed some texmf files, fontname and web2c directories from tetex-bin/beta. For some reason, Debian has some web2c stuff (esp. the .pool files) in the tetex-bin package, just like you had before; although they're distributed by upstream in the texmf tree. I think I'll just re-include all these files in the texmf-base and texmf-tiny packages, is that ok? Greetings, Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: tetex-beta-20001218 available for testing
"Jérôme-Georges-Michel BENOIT" <[EMAIL PROTECTED]> writes: > > Last night, I've rebuild the texmf packages, but I found that you > > removed some texmf files, fontname and web2c > >directories from tetex-bin/beta. > > This a big bug: I have to fix it: > I have to reinclude them in the next rebuilt > because the web2c directory contains > binaries stuff (as the POOL file): > DO NOT include them in texmf-*. Ok, good. > I will fix it soon, When you upload, is there a place I can download them from? Last night I waited until the first japanese mirror carried them %-/ Greetings, Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: [ANN] apache_1.3.22-2
Corinna Vinschen <[EMAIL PROTECTED]> writes: > I agree with your disagreeing here. It might not be very > concise to have different names for these dirs but it's > "common sense" or so. Common sense? Maybe you've been running exclusively Red Hat for too long. [ducks and runs] Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: tetex-beta-20001218 available for testing
"Jérôme-Georges-Michel BENOIT" <[EMAIL PROTECTED]> writes: > The orignal name of main source is `tetex-beta-20001218': Indeed, so please just name the new bugfixed package tetex-beta-20001218-3. > but this operation should take some time and the 'list' asked me to > rebuid the current cygwin package before that this new source was > available. I've got a set of texmf-*-20001218 packages in a ready-when-you-are state for quite some time now. Let's please get them out asap, so that we can take our time handling the new upstream later. Greetings, Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
texmf matching new tetex-beta-20001218-3
Hi List, Last night, I've built the texmf-* suite matching Jerome's latest rebuild tetex-beta-20001218-3. It is available for testing at: http://lilypond.org/cygwin/testing/tar/texmf Note: * These packages depend on tetex-beta-20001218-3 for full operation. * If you install by hand, run /etc/postinstall/post-texmf.sh. * If you have MiKTeX installed, please be sure to remove any custom TEXINPUTS, MFINPUTS etc. environment settings that contain DOS style paths. * TeX cannot handle spaces in file names. If your $HOME contains spaces, you may need to run TeX from another cwd, eg, /tmp. Would someone be so kind to take a look and load it up if everything is OK? After a successful installation, you should be able to run, eg, latex sample2e Greetings, Jan. [there may be a working setup.ini at http://lilypond.org/cygwin/testing] http://lilypond.org/cygwin/testing/tar/texmf/setup.hint sdesc: "The TeX text formatting system (install helper)" ldesc: "A dependency on this package installs a usable TeX installation." category: Text requires: cygwin tetex-beta texmf-base # requires: cygwin tetex-beta texmf-base|texmf-tiny http://lilypond.org/cygwin/testing/tar/texmf/texmf-2804-2.README http://lilypond.org/cygwin/testing/tar/texmf/texmf-2804-2-src.tar.bz2 http://lilypond.org/cygwin/testing/tar/texmf/texmf-2804-2.tar.bz2 === http://lilypond.org/cygwin/testing/tar/texmf/texmf-base/setup.hint sdesc: "The TeX text formatting system (basic libraries)" ldesc: "Basic library files for the Cygwin teTeX distribution. Together with tetex-beta you have a useful TeX installation. With texmf-extra, you have a complete installation." category: Text requires: ash cygwin ed jpeg libncurses6 libpng tiff sed termcap tetex-beta zlib #suggests: texmf-extra texmf-doc http://lilypond.org/cygwin/testing/tar/texmf/texmf-base/texmf-base-2804-2.tar.bz2 === http://lilypond.org/cygwin/testing/tar/texmf/texmf-doc/setup.hint sdesc: "The TeX text formatting system (documentation)" ldesc: "Documentation for the Cygwin teTeX distribution" category: Doc requires: cygwin http://lilypond.org/cygwin/testing/tar/texmf/texmf-doc/texmf-doc-2804-2.tar.bz2 === http://lilypond.org/cygwin/testing/tar/texmf/texmf-extra/setup.hint sdesc: "The TeX text formatting system (extra libraries)" ldesc: "Extra library files for the Cygwin teTeX distribution. Together with tetex-beta and texmf-base you have a complete TeX installation." category: Text requires: tetex-beta texmf-base http://lilypond.org/cygwin/testing/tar/texmf/texmf-extra/texmf-extra-2804-2.tar.bz2 === http://lilypond.org/cygwin/testing/tar/texmf/texmf-tiny/setup.hint sdesc: "The TeX text formatting system (tiny libraries subset)" ldesc: "Very small subset of library files for the Cygwin teTeX distribution. Together with tetex-beta you have a minimal TeX installation. For a reasonable TeX installation, texmf-base is recommended." category: Text requires: ash cygwin ed jpeg libncurses6 libpng tiff sed termcap tetex-beta zlib http://lilypond.org/cygwin/testing/tar/texmf/texmf-tiny/texmf-tiny-2804-2.tar.bz2 -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
comments on texmf package?
Hi, Probably I'm too impatient, but I've been waiting so long for a full tex setup in Cygwin... Who will be looking at the new texmf packages? http://cygwin.com/ml/cygwin-apps/2002-01/msg00311.html Greetings, Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: comments on texmf package?
Corinna Vinschen <[EMAIL PROTECTED]> writes: > I'm not at all familar with tex so I'd like to ask somebody else > to look into these packages. The setup.hint files are looking ok to > me. Did you pack using the correct paths as given on > http://cygwin.com/setup.html#package_contents ? Yes, I believe so. > Another point: Aren't we still waiting for tetex-beta-20001218-3 > leaving `test' state or did I miss something? Yes it seems that way. In this case that's maybe a bit odd, because tetex-beta-20001218-1 has a number of problems. > IMO it doesn't make much sense to have these texmf packages in > `curr' state if they depend on a `test' package. Ok, so maybe adding some test: tags would not hurt. In any case, tetex-beta-20001218-3 and texmf-*' tags should be (kept) in sync. Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: gcc -mno-cygwin STL support for setup.exe?
Christopher Faylor <[EMAIL PROTECTED]> writes:
> The biggest issue with relying on libstdc++.a for for setup.exe is that it
> requires this library to be built for cross-compilation. I have no idea how
> to do that.
What am I missing?
19:37:40 fred@appel:~$ locate libstdc++.a | grep x-
/home/cygwin/cygwin-1.3.3/linux-x-cygwin/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/libstdc++.a
/home/cygwin/cygwin-1.3.3/linux-x-cygwin/usr/lib/libstdc++.a.2.10.0
/home/cygwin/cygwin-1.3.6/linux-x-cygwin/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/libstdc++.a
/home/cygwin/cygwin-1.3.6/linux-x-cygwin/usr/lib/libstdc++.a.2.10.0
This x-compiles fine here
#include
#include
int
main ()
{
string s = "Hello world";
cout << s << endl;
return 0;
}
Greetings,
Jan.
--
Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org
texmf packages ready
Hi, The texmf packages have been available for a week now, so cc'ing the cygwin list so that other people can use them. Greetings, Jan. From: Jan Nieuwenhuizen <[EMAIL PROTECTED]> Subject: texmf matching new tetex-beta-20001218-3 To: [EMAIL PROTECTED] Date: 16 Jan 2002 13:01:57 +0100 Organization: Jan at Appel Hi List, Last night, I've built the texmf-* suite matching Jerome's latest rebuild tetex-beta-20001218-3. It is available for testing at: http://lilypond.org/cygwin/testing/tar/texmf Note: * These packages depend on tetex-beta-20001218-3 for full operation. * If you install by hand, run /etc/postinstall/post-texmf.sh. * If you have MiKTeX installed, please be sure to remove any custom TEXINPUTS, MFINPUTS etc. environment settings that contain DOS style paths. * TeX cannot handle spaces in file names. If your $HOME contains spaces, you may need to run TeX from another cwd, eg, /tmp. Would someone be so kind to take a look and load it up if everything is OK? After a successful installation, you should be able to run, eg, latex sample2e Greetings, Jan. [there may be a working setup.ini at http://lilypond.org/cygwin/testing] http://lilypond.org/cygwin/testing/tar/texmf/setup.hint sdesc: "The TeX text formatting system (install helper)" ldesc: "A dependency on this package installs a usable TeX installation." category: Text requires: cygwin tetex-beta texmf-base # requires: cygwin tetex-beta texmf-base|texmf-tiny http://lilypond.org/cygwin/testing/tar/texmf/texmf-2804-2.README http://lilypond.org/cygwin/testing/tar/texmf/texmf-2804-2-src.tar.bz2 http://lilypond.org/cygwin/testing/tar/texmf/texmf-2804-2.tar.bz2 === http://lilypond.org/cygwin/testing/tar/texmf/texmf-base/setup.hint sdesc: "The TeX text formatting system (basic libraries)" ldesc: "Basic library files for the Cygwin teTeX distribution. Together with tetex-beta you have a useful TeX installation. With texmf-extra, you have a complete installation." category: Text requires: ash cygwin ed jpeg libncurses6 libpng tiff sed termcap tetex-beta zlib #suggests: texmf-extra texmf-doc http://lilypond.org/cygwin/testing/tar/texmf/texmf-base/texmf-base-2804-2.tar.bz2 === http://lilypond.org/cygwin/testing/tar/texmf/texmf-doc/setup.hint sdesc: "The TeX text formatting system (documentation)" ldesc: "Documentation for the Cygwin teTeX distribution" category: Doc requires: cygwin http://lilypond.org/cygwin/testing/tar/texmf/texmf-doc/texmf-doc-2804-2.tar.bz2 === http://lilypond.org/cygwin/testing/tar/texmf/texmf-extra/setup.hint sdesc: "The TeX text formatting system (extra libraries)" ldesc: "Extra library files for the Cygwin teTeX distribution. Together with tetex-beta and texmf-base you have a complete TeX installation." category: Text requires: tetex-beta texmf-base http://lilypond.org/cygwin/testing/tar/texmf/texmf-extra/texmf-extra-2804-2.tar.bz2 === http://lilypond.org/cygwin/testing/tar/texmf/texmf-tiny/setup.hint sdesc: "The TeX text formatting system (tiny libraries subset)" ldesc: "Very small subset of library files for the Cygwin teTeX distribution. Together with tetex-beta you have a minimal TeX installation. For a reasonable TeX installation, texmf-base is recommended." category: Text requires: ash cygwin ed jpeg libncurses6 libpng tiff sed termcap tetex-beta zlib http://lilypond.org/cygwin/testing/tar/texmf/texmf-tiny/texmf-tiny-2804-2.tar.bz2 -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Texmf stalled, or waiting for votes?
Hi, What's the status of the texmf packages? I expected to probably get some comment on the hint files (Corinna said they seemed ok, but didn't know too much about TeX), or some other suggestions for the packages; and hoped they'd be uploaded to contrib some time after. Possibly we're still waiting for a third aye vote? Greetings, Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: Texmf stalled, or waiting for votes?
"Jérôme-Georges-Michel BENOIT" <[EMAIL PROTECTED]> writes: > I have just checked the texmf-* tarballs: Ok, thanks. > in the directory 'usr/doc' the subdirectory `cygwin' is `cygwin' but > not `Cygwin' (the first charactere is a lower case). Hmm, strange. It looks ok here: tar tjf ~/g/tar/texmf/texmf-2804-2.tar.bz2 | grep Cygwin usr/doc/Cygwin/ usr/doc/Cygwin/texmf-2804-2.README Maybe you already had a `usr/doc/cygwin' ligging around? That would prevent creating the capitalised Cygwin from being created. > Otherwise I wonder if we can install and uninstall the tetex-beta > and texmf-* packages without damages: on my computer the > uninstallation of `tetex-beta' modify the directory > `/usr/share/texmf' and I have to make some fixes by hand. Yes. I've made a patch for setup.exe, which has been included, so that it now accepts pre- and postremove scripts. The difficult thing is to figure out what exactly should be done, and when. > I guess that the next step to see that is to make the texmf-* > available for test for a while in such a way we can adjust > tetex-beta and texmf-*. Yes, I would think so too. I've received a few good reports, and sent one small problem with solution to the cygwin list this week. Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: usr/doc/[cC]ygwin requirement
"Jérôme-Georges-Michel BENOIT" <[EMAIL PROTECTED]> writes: >>usr/doc/Cygwin/texmf-2804-2.README > > my /usr/doc/cygwin is not capitalized, > hence my remark. Ah, ok. I don't think this is of much importance, but cygwin.com/setup.html says: * In your binary package, include a file /usr/doc/Cygwin/foo-vendor-suffix.README Before I went there to check, I tried to look if there was a convention for this, but strangely enough, none of the packages I checked had a usr/doc/Cygwin at all (cygwin, bash, gawk, textutils, ed)?. Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
[ping] [WAS: Re: Texmf stalled, or waiting for votes?]
Corinna Vinschen <[EMAIL PROTECTED]> writes: > As per Jerome's suggestion you should add the test markers to > your hint files and when you ping that you're ready, I'll upload > them, ok? Ok thanks. I've added the test markers. > If you could give the URL again in your mail, I'd appreciate it :-) Sure. Here's the toplevel url, find the specific urls below. http://lilypond.org/cygwin/testing/tar/texmf Greetings, Jan. http://lilypond.org/cygwin/testing/tar/texmf/setup.hint sdesc: "The TeX text formatting system (install helper)" ldesc: "A dependency on this package installs a usable TeX installation." category: Text requires: cygwin tetex-beta texmf-base # requires: cygwin tetex-beta texmf-base|texmf-tiny test: 2804-2 http://lilypond.org/cygwin/testing/tar/texmf/texmf-2804-2.README http://lilypond.org/cygwin/testing/tar/texmf/texmf-2804-2-src.tar.bz2 http://lilypond.org/cygwin/testing/tar/texmf/texmf-2804-2.tar.bz2 === http://lilypond.org/cygwin/testing/tar/texmf/texmf-base/setup.hint sdesc: "The TeX text formatting system (basic libraries)" ldesc: "Basic library files for the Cygwin teTeX distribution. Together with tetex-beta you have a useful TeX installation. With texmf-extra, you have a complete installation." category: Text requires: ash cygwin ed jpeg libncurses6 libpng tiff sed termcap tetex-beta zlib #suggests: texmf-extra texmf-doc test: 2804-2 http://lilypond.org/cygwin/testing/tar/texmf/texmf-base/texmf-base-2804-2.tar.bz2 === http://lilypond.org/cygwin/testing/tar/texmf/texmf-doc/setup.hint sdesc: "The TeX text formatting system (documentation)" ldesc: "Documentation for the Cygwin teTeX distribution" category: Doc requires: cygwin test: 2804-2 http://lilypond.org/cygwin/testing/tar/texmf/texmf-doc/texmf-doc-2804-2.tar.bz2 === http://lilypond.org/cygwin/testing/tar/texmf/texmf-extra/setup.hint sdesc: "The TeX text formatting system (extra libraries)" ldesc: "Extra library files for the Cygwin teTeX distribution. Together with tetex-beta and texmf-base you have a complete TeX installation." category: Text requires: tetex-beta texmf-base test: 2804-2 http://lilypond.org/cygwin/testing/tar/texmf/texmf-extra/texmf-extra-2804-2.tar.bz2 === http://lilypond.org/cygwin/testing/tar/texmf/texmf-tiny/setup.hint sdesc: "The TeX text formatting system (tiny libraries subset)" ldesc: "Very small subset of library files for the Cygwin teTeX distribution. Together with tetex-beta you have a minimal TeX installation. For a reasonable TeX installation, texmf-base is recommended." category: Text requires: ash cygwin ed jpeg libncurses6 libpng tiff sed termcap tetex-beta zlib test: 2804-2 http://lilypond.org/cygwin/testing/tar/texmf/texmf-tiny/texmf-tiny-2804-2.tar.bz2 -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: [ping] [WAS: Re: Texmf stalled, or waiting for votes?]
Corinna Vinschen <[EMAIL PROTECTED]> writes: > Thanks. I've loaded it up to cygwin.com. Please prepare an > announcement according to http://cygwin.com/setup.html#submitting, > point 9. Please wait some hours until at least a few mirrors > had a chance to get the package. All done (that includes the waiting :-) Thanks a lot, Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
pregerenated cinstall/configure broken in cvs
Hi,
I've sent a patch a while ago that included a 'fix' for
cinstall/configure.in wrt CFLAGS; but I could not reproduce the error,
so it was removed.
It turns out that the pregenerated configure in cinstall is buggy.
Can someone check in a freshly generated configure?
After a fresh checkout, I get:
11:32:51 fred@appel:~cinstall$ MINGW32=yes CFLAGS='-mno-cygwin' ./configure
creating cache ./config.cache
checking host system type... powerpc-unknown-linux-gnu
checking target system type... powerpc-unknown-linux-gnu
checking build system type... powerpc-unknown-linux-gnu
checking for gcc... gcc
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking for g++... g++
./configure: CFLAGS: command not found
Running autoconf makes this go away (no patch needed), that's why we
couldn't reproduce it. Here's a snippet of the pre/post autoconf diff:
diff -u ../cinstall.orig/configure .
[..]
@@ -886,7 +875,7 @@
test -z "$CC" && { echo "configure: error: no acceptable cc found in \$PATH"
1>&2; exit 1; }
fi
-CXXFLAGS="$(CFLAGS)"
+CXXFLAGS='$(CFLAGS)'
if test "$program_transform_name" = s,x,x,; then
Greetings,
Jan.
--
Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: pregerenated cinstall/configure broken in cvs
Christopher Faylor <[EMAIL PROTECTED]> writes: >>11:32:51 fred@appel:~cinstall$ MINGW32=yes CFLAGS='-mno-cygwin' ./configure > > > Why are you doing this? It's not necessary. I don't know. It was in ancient times, to avoid linking to cygwin1.dll, and haven't ever checked since. Thanks for the hint, I'll look into it. > Regardless, I've regenerated the configure script. I'm not sure why > it was in that state. Thanks, Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: pregerenated cinstall/configure broken in cvs
Christopher Faylor <[EMAIL PROTECTED]> writes: > I sincerely doubt this. I've been working with setup.exe for a while now > and I've never had to do this. You're right. It's not needed. > IF I had to do this, I would have fixed the problem not kludged > around it (hint). Just fixed some other small bug, will I still lose points? :-) Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: md5sum of texmf-doc does not match?
Servaas Goossens <[EMAIL PROTECTED]> writes: > (I send this to you because of your recent announcement of > texmf-2804-2 on [EMAIL PROTECTED] I am not a regular > user of texmf. Please excuse me if this is not the right > place for this issue.) I'm the maintainer for cygwin, but seems that its not something I can do much about, cc'ing reply to cygwin-apps. > I just downloaded the newest cygwin packages; > It appears the md5sum does not match for one file. It seems that the md5sum generated at cygwin is not correct: > $ md5sum cygwin/contrib/texmf/texmf-doc/texmf-doc-2804-2.tar.bz2 > eb532d399c49bde15d10ef559f0c6f11 *texmf-doc-2804-2.tar.bz2 because I get the same here as you do: 16:16:13 jan@esac-pc:~/g/tar/texmf/texmf-doc$ cat md5.sum eb532d399c49bde15d10ef559f0c6f11 tar/texmf/texmf-doc/texmf-doc-2804-2.tar.bz2 16:16:15 jan@esac-pc:~/g/tar/texmf/texmf-doc$ md5sum texmf-doc-2804-2.tar.bz2 eb532d399c49bde15d10ef559f0c6f11 texmf-doc-2804-2.tar.bz2 > $ cat cygwin/contrib/texmf/texmf-doc/md5.sum > f4751de5359e0e119c27fb7cd9f1160e setup.hint > 489cf538d03bc4cc9ce4e47a66123468 texmf-doc-2804-2.tar.bz2 > > I get consistent results for these two mirror sites: > ftp://sunsite.cnlab-switch.ch/mirror/cygwin/ > ftp://ftp.ccp14.dl.ac.uk/ccp14/ftp-mirror/programming/cygwin/pub/cygwin/ Have you checked other files? Greetings, Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: CVS setup.exe doesn't update zlib
"Michael A Chase" <[EMAIL PROTECTED]> writes: > I've been using the latest CVS version of setup.exe for a couple weeks now. > The only real problem I'm seeing is that it won't update zlib. I thought I > saw a proposed patch for that go by a while ago, but I don't have it now. But I have it, it got backed-up on the internet. http://sources.redhat.com/ml/cygwin-patches/2002-q1/msg00198.html Greetings, Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
setup.exe /var, /tmp?
Hi, I've tried a fresh install, using a newly built setup200202 setup.exe, but it seems that /var and /tmp are not being created any more. I'm fairly sure that at least /var used to be created by setup.exe automagically. Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: setup.exe /var, /tmp?
"Robert Collins" <[EMAIL PROTECTED]> writes: > Please try this patch... Hmm, this doesn't help. Similar fix applied to install.cc also doesn't help. After removing c:/cygwin and doing a fresh install, you get the error message: cannot open log file C:/cygwin/var/log/setup.log.full for writing. (but that's not as bad as that tetex/texmf will fail until /var gets created :-). Also, in the select packages dialog, when expanding a category, packages are often not visible; just empty spaces. It seems to be some kind of redraw problem; it works somewhat for categories near the top of the list, but not for categories below the center; ie, this is what I see after expanding some categories: + All () Default + Base () Default + Devel () Default + Doc () Default + Editors () Default 0-2-1 () Keep [] ed: The GNU versio|-> rest of line blank + Graphics () Default + Interpreters () Default + Libs () Default + Net () Default + Publishing () Default + Shells () Default + Text () Default See also http://appel.lilypond.org/lilypond/cygwin/setup.jpeg Greetings, Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: setup.exe /var, /tmp?
"Robert Collins" <[EMAIL PROTECTED]> writes: > Install.cc doesn't need that fix. It needs a different one I think - see > if this helps. Yes, this helps. What about /home[/]? > As for the graphics problem, I can't reproduce it here, Ok. That was on a windows98 box... Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: setup.exe /var, /tmp?
"Robert Collins" <[EMAIL PROTECTED]> writes: > Jan, > is this fully sorted with the last patch I sent you? Yes, that second file:// patch was fine. Greetings, Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: Packaging tools? (Was: RE: RFP: NASM)
Stanislav Sinyagin <[EMAIL PROTECTED]> writes: > Did someone think of developing a simple framework for making the > packages, especially for that software which supports Cygwin and > configure does everything for you? Not a simple script, but I've built a cardhouse of scripts that setup a cross-compile environment, and then downloads and does > something like >cygmkpkg expat-1.95.2.tar.gz > and that's it? this for any number of `native' packages See http://lilypond.org/cygwin/cygwin-cross.tar.gz Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: Packaging tools? (Was: RE: RFP: NASM)
Christopher Faylor <[EMAIL PROTECTED]> writes: >>> See >>> http://lilypond.org/cygwin/cygwin-cross.tar.gz >> >>Then, could someone include this link into the contributor's guide >> http://cygwin.com/setup.html >>and maybe links to some other scripts like that? > > A link to some other site with another cygwin distribution? > > No. Fwiw, I'd like to get rid of `that other site' too; packaging texmf was a first big step towards that. When we have guile in the official Cygwin release, I'm intending to give contributing a LilyPond package a go. Greetings, Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
move texmf-* out of test?
Hi, As tetex-beta-20001218-4 (now in curr) and texmf-*-2804-2 seem to work well together, can we remove the test marker from texmf? I thought there was a three weeks period for test; who's keeping track of that? We've had some complaints, esp. wrt setup.exe suggesting to downgrade tetex (see cygwin list of this week). Greetings, Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: move texmf-* out of test?
Charles Wilson <[EMAIL PROTECTED]> writes: >> As tetex-beta-20001218-4 (now in curr) and texmf-*-2804-2 seem to >> work well together, can we remove the test marker from texmf? > > You are the maintainer; it is your decision. > > I don't know of any hard rule about "three weeks" -- whatever you, as > the maintainer, think is appropriate for your packages, is good. Indeed, I reread setup.html; must have dreamt it up. But how do I go about moving texmf-* to curr? Would this asking here be enough? No big problems have shown up, it seems a waste to release a new version (-3) of such a large package (~30mb binaries, 30mb sources) without major changes. Greetings, Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: move texmf-* out of test?
Charles Wilson <[EMAIL PROTECTED]> writes: > Right now, yes -- it requires someone with a shell account on > sourceware to edit the setup.hint file -- or scp up a new copy of the > setup.hint file -- which contains the necessary changes. Ok. > Sounds like you have a reasonable basis for your decision. :-) Do you > want me to fixup texmf*/setup.hint? :-) Yes, please. There are four of them. Greetings, Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: move texmf-* out of test?
Charles Wilson <[EMAIL PROTECTED]> writes: > Somebody beat me to it -- they have already been promoted. Why, somebody must have overheard us chitchatting then, was I really talking that loud? :-) Thanks, to someone too. Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: xfree packages
Christopher Faylor <[EMAIL PROTECTED]> writes: > I think that these files should be called XFree86-base (or just > XFree86), etc. The project is the Cygwin/XFree86 project and I > think the package names should reflect that. Oh no, please reconsider allowing capitals in package names? You'll set a precedent for teTeX, GUILE, MySQL etc. I'd vote for xfree86. Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: xfree packages
"Robert Collins" <[EMAIL PROTECTED]> writes: > Setup is case insensitive to package names. I don't see any technical > issue either way. Me neither, I only see a social issue: it's just plain irritating for people? tar xjf releases/mysTABTAB ^U tar xjf releases/MyTABTAB ^U etc, aargh? It's ever more annoying when you're using wget, and try to guess the name. Well, it's only a minor pain, and maybe it's just me. Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: xfree packages
Christopher Faylor <[EMAIL PROTECTED]> writes: > AFAICT, both Red Hat and Debian allow upper/lower case, so there's no > reason for us to restrict things. All Debian packages are lower case, of course. TAB completion is a silly argument against using mixed case, but I just couldn't imagine anyone would want mixed case package names, if they had a choice. Probably a matter of taste, I'll try to get used to it :-) Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: 'release' directory now active
Christopher Faylor <[EMAIL PROTECTED]> writes: > The affected subdirectories were readline/*, > texmf/*, libpng/* . > However, maintainers of these packages, please check to see that I got > this right. I've looked at texmf/*, the file sizes I see with ftp are correct, so modulo something weird, it should be ok. My favorite mirror (ftp://sunsite.auc.dk/mirrors/cygwin) doesn't carry /release yet, and I can't download from cygwin.com, of course. Greetings, Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: Uninstall scripts?
"Jon Foster" <[EMAIL PROTECTED]> writes: > I know that after I install a package, setup.exe runs the > postinstall script /etc/postinstall/.sh. Is > there an equivalent script which is run before a package > is uninstalled? Yes, there's /etc/preremove/.sh /etc/postremove/.sh It hasn't been in wide use, afaik, Greetings, Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: setup changes to build standalone
"Robert Collins" <[EMAIL PROTECTED]> writes: > Heh. The main things I get from automake is > a) make dist. I _love_ this so much it ain't funny. If you're willing to depend on gnu make features, make dist is no rocket science. Because of the horrors of automake, we've implemented a sane set of make rules, mainly for LilyPond, that has all these features and allows > e) non-recursive makefiles of a reasonable size. a make file for a library or executable typically about 10 lines long. Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: setup changes to build standalone
"Robert Collins" <[EMAIL PROTECTED]> writes: > Sure. I'm not relying on gnu make features though. Yes, then things get a lot more awkward. > I'll have a look at some point. I actually find automake much less > horrible that doing everything by hand. Anyway, this is off-topic here - > unless you are objecting to setup being automakified? No, it's rather off-topic, sorry. > Ermm, most of my projects have much more than 10 lines just listing the > source. Yes, that's the price you pay when not using wildcards, but that can't be avoided. If you'd want to dist everything that's in cvs (ie, CVS/Entries), there could be a way out of that listing. Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
ITP: netpbm
Hi list, Today I've taken a look at the netpbm package. Pierre Humblet, who's listed as Cygwin porter, is not considering to contribute it as Cygwin package, but was fine with me packaging it. I've only done a few quick tests, from ps->pnm->png. URLs below. Cast your votes now. Greetings, Jan. http://lilypond.org/cygwin/tar/netpbm/setup.hint sdesc: "Graphics conversion tools" category: Graphics requires: cygwin jpeg libpng tiff zlib # build-requires: cygwin jpeg libpng libpng-devel tiff zlib ldesc: "Netpbm is a toolkit for manipulation of graphic images, including conversion of images between a variety of different formats. There are over 220 separate tools in the package including converters for more than 80 graphics formats." http://lilypond.org/cygwin/tar/netpbm/netpbm-9.25-1-src.tar.bz2 http://lilypond.org/cygwin/tar/netpbm/netpbm-9.25-1.tar.bz2 -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: ITP: netpbm
Charles Wilson <[EMAIL PROTECTED]> writes: > Wonderful, please do. Ok. I've been away from email, as you noticed, and will be back tonight (CET). I'll have to consider if any big problems arise, because this mustn't turn into a time sink. > BTW, I have had a private version of netpbm, packaged in a > 'setup-compatible' way, for some time now. When I get home, I'll put > my version somewhere that you can access; you may want to expropriate > some of my patches... Ok, I'd like to have a look. What do these patches do, ie, (why) can't they flow upstream? > Also, which png have you linked against? 1.0.12, or 1.0.13? 1.0.13. I'll change dependencies to libpng10, and will split the package into netpbm, libnetpbm9, libnetpbm9-dev[el], simply mimicking what Debian is doing; that should be enough? I'll have to read up to the # binaries thing, the only thing I would like to consider* is moving /usr/bin to /usr/bin/netpbm, but I'd rather not. Greetings, Jan. * but only if there's a good reason because of broken filesystem and lookup support, and some sort of consensus (summary, anyone? :-) -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: ITP: netpbm
Charles Wilson <[EMAIL PROTECTED]> writes: > Well, as I described in the other message, there are only three > patches. Ok, I must have looked over it. > One, which creates a Makefile.config, > Two, a cygwin-specific README file. > Three, GNU shtool, to create a shadow tree in which to build. Indeed, I've done something quite similar, of course, but it seems that you've put more work in it than I, already. > What *would* be appropriate is if someone totally autoconfiscated the > whole mess, Yes, but I guess we'll leave that up to the authors, or, at least, ask them first. It shouldn't be much work, there seem to be a few system profiles, and then some questions. > Big directories == slow. Much worse on FAT than on NTFS. There's no > hard limit on non-partition-root directories, however (unless somebody > does something REALLY silly, like 'mount C:\ /bin'. > > Putting all the netpbm binaries in /usr/bin(==/bin) won't cause any > problems, except for the standard PATH ordering issues(*), but those > will only affect a few people (like me, and I can deal). Ok. I think plainly in usr/bin would be best, because it's standard, but things can be changed/ moved around whenever this list decides something else. Also, I think that this > (*) there are widely used windows ports of netpbm tools. [..] So, > in normal windows, and cmd prompt, I use the native port of netpbm > [..] When in bash, I use the cygwin port of netpbm (this makes me > happy). while, a valid argument, can probably be said for tex itself (tex,latex etc), for gs (ghostscript), probably even the 'find' command. I think that if 'you' want some subset of bin in certain situations, you should probably arrange that yourself. Greetings, Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: Error in configuring setup.
Earnie Boyd <[EMAIL PROTECTED]> writes: >> Upon Robert's insistance I've installed the autotools. :( Now after >> about 10 iterations of aclocal, libtoolize, autoconf I: >> >> And toward the configure ends with: > s/toward// >> >> configure: configuring in libgetopt++ Yes, it seems something strange is going on here. It would be very nice too, if the libgetopt++ directory had a pregenerated ./configure. Also, after checking out setup: cvs -d :pserver:[EMAIL PROTECTED]:/cvs/cygwin-apps co setup I also get setup/libgetopt++, setup/cfgaux (and zlib and, bzlib, of course), but after removing setup/libgetop++ and setup/cfgaux and doing an cvs update -d in ./setup, libgetopt++ and cfgaux are not fetched from cvs. Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: libpng dependencies
Charles Wilson <[EMAIL PROTECTED]> writes: > Attn maintainers: > > Please check your setup.hints: >texmf-base >texmf-tiny These just list dependencies on which tetex-beta depends. That is to say, the postinstall scripts run tetex-beta binaries (need: cygwin jpeg libncurses6 libpngXX tiff termcap zlib) and scripts (need: ash, awk, ed, sed), but previous releases of tetex-beta didn't seem to have full correct dependencies set. As soon as tetex-beta's dependencies are complete, dependencies of these texmf-* packages may be dropped. Greetings, Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
libstdc++ for building setup.exe
Hi, I haven't been able to build the new setup (since it moved in cvs), but that may be due to the fact that the mingw package was dropped. At http://sources.redhat.com/cygwin-apps/setup.html it says: To successfully build such a setup you will need a mingw libstdc++.a file for the cross-compiler to link against. One can be found in the mingw gcc binary Is libstdc++.a the only mingw library that's needed, and do you have an url for it? Previously, untarring the mingw and mingw-runtime packages was sufficient. Last thing I tried was the rather old, but apparently latest mingw gcc package to contain a libstdc++: ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/cygwin/gcc-2.95.2/gcc-2.95.2-mingw-extra.tar.gz but I still get missing _impure_ptr errors. Greetings, Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: libstdc++ for building setup.exe
Charles Wilson <[EMAIL PROTECTED]> writes: > You can also download this: > > >http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/release/mingw-extra/mingw-extra-2.95.3_20011106-2.tar.bz2 > > and unpack it in the obvious place. It contains those libraries from > mingw's gcc package. You might also want to manually run the > "postinstall" script. Thanks a lot. It would be helpful to add some pointers to setup's application page. However, when I said 'build', I really meant cross-build. Anyway, I'm almost there now. I've no clue whether I'm using incorrect header files, incorrect libraries, or just need an extra library. This is on a cygwin-1.3.10 based cross-install. Jan. 12:29:17 fred@peder:~/cvs/cygwin/cygwin-apps/setup-build $ g++ -mno-cygwin -Werror -Winline -Wall -Wpointer-arith -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wcomments -g -O2 -o setup.exe -mwindows archive.o archive_tar.o archive_tar_file.o autoload.o category.o choose.o cistring.o compress.o compress_bz.o compress_gz.o concat.o cygpackage.o desktop.o dialog.o diskfull.o download.o Exception.o find.o FindVisitor.o filemanip.o fromcwd.o geturl.o hash.o ini.o IniDBBuilder.o IniDBBuilderPackage.o inilex.o iniparse.o IniParseFeedback.o IniParseFindVisitor.o install.o io_stream.o io_stream_cygfile.o io_stream_file.o io_stream_memory.o localdir.o log.o LogFile.o LogSingleton.o main.o md5.o MD5++.o mkdir.o mklink2.o mount.o msg.o net.o netio.o nio-ie5.o nio-file.o nio-ftp.o nio-http.o package_db.o package_meta.o package_source.o package_version.o PickCategoryLine.o PickLine.o PickPackageLine.o PickView.o postinstall.o proppage.o propsheet.o rfc1738.o root.o ScanFindVisitor.o script.o setup_version.o simpsock.o site.o source.o splash.o state.o String++.o threebar.o version.o win32.o window.o res.o -L/home/fred/usr/src/cygwin/cygwin-1.3.10/usr/lib/mingw -L/home/fred/usr/src/cygwin/cygwin-1.3.10/linux-cygwin/usr/i686-pc-cygwin/lib/mingw zlib/libzcygw.a bz2lib/libbz2.a libgetopt++/.libs/libgetopt++.a -lstdc++ -luser32 -lkernel32 -lcomctl32 -lole32 -lwsock32 -lnetapi32 -ladvapi32 -luuid -lmingw32 Warning: resolving __ctype_ by linking to __imp___ctype_ (auto-import) bz2lib/libbz2.a(bzlib.o): In function `bzopen_or_bzdopen': /home/fred/cvs/cygwin/cygwin-apps/setup-build/bz2lib/../../setup/bz2lib/bzlib.c:1424: variable '_ctype_' can't be auto-imported. Please read the documentation for ld's --enable-auto-import for details. LogFile.o: In function `_tf8_IO_FILE': /home/fred/cvs/cygwin/cygwin-apps/setup-build/../setup/LogFile.cc(.data$_vt$12strstreambuf+0x34): undefined reference to `streambuf::xsputn(char const *, long)'/home/fred/cvs/cygwin/cygwin-apps/setup-build/../setup/LogFile.cc(.data$_vt$12strstreambuf+0x3c): undefined reference to `streambuf::xsgetn(char *, long)' /home/fred/cvs/cygwin/cygwin-apps/setup-build/../setup/LogFile.cc(.data$_vt$12strstreambuf+0x6c): undefined reference to `streambuf::sys_read(char *, long)' /home/fred/cvs/cygwin/cygwin-apps/setup-build/../setup/LogFile.cc(.data$_vt$12strstreambuf+0x74): undefined reference to `streambuf::sys_write(char const *, long)' libgetopt++/.libs/libgetopt++.a(OptionSet.o): In function `$_t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0': /home/fred/cvs/cygwin/cygwin-apps/setup-build/libgetopt++/../../setup/libgetopt++/src/OptionSet.cc(.text$__ls__H3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0_R7ostreamRCt12basic_string3ZX01ZX11ZX21_R7ostream+0x18): undefined reference to `ostream::write(char const *, long)' collect2: ld returned 1 exit status -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
building setup.exe -- solved
Hi, Finally, I found the problem. I'm including the error messages I got for others to find. Here's what I've been struggling with: g++ -v -mno-cygwin -o setup.exe ... -lmingw32 ... /home/fred/cvs/cygwin/cygwin-apps/setup-build/bz2lib/../../setup/bz2lib/bzlib.c:866: undefined reference to `_impure_ptr' bz2lib/libbz2.a(bzlib.o): In function `bzopen_or_bzdopen': /home/fred/cvs/cygwin/cygwin-apps/setup-build/bz2lib/../../setup/bz2lib/bzlib.c:1424: undefined reference to `_ctype_' ... And, adding -lg: g++ -v -mno-cygwin -o setup.exe ... -lmingw32 -lg Warning: resolving __ctype_ by linking to __imp___ctype_ (auto-import) bz2lib/libbz2.a(bzlib.o): In function `bzopen_or_bzdopen': /home/fred/cvs/cygwin/cygwin-apps/setup-build/bz2lib/../../setup/bz2lib/bzlib.c:1424: variable '_ctype_' can't be auto-imported. Please read the documentation for ld's --enable-auto-import for details. collect2: ld returned 1 exit status It turned out to be a rather silly bug (once you know it): CPPFLAGS, when passed to ./configure (like setup's webpage advertises), doesn't make in into bz2lib/Makefile. When using a gcc -mno-cygwin cross-compiler on linux, you need to override CPPFLAGS for bz2lib too, so that mingw's _G_config.h and other mingw headers get included. I would like to suggest the patch below. Greetings, Jan. 12:40:55 fred@peder:~/cvs/cygwin/cygwin-apps/setup $ diff -u bz2lib/configure.in.orig bz2lib/configure.in --- bz2lib/configure.in.origFri Jun 14 12:35:07 2002 +++ bz2lib/configure.in Fri Jun 14 12:36:09 2002 @@ -7,7 +7,7 @@ AM_INIT_AUTOMAKE(libbz2, 0.0) AM_MAINTAINER_MODE -CPPFLAGS=-U_WIN32 +CPPFLAGS="$CPPFLAGS -U_WIN32" AC_CANONICAL_HOST AC_PROG_CC AC_PROG_RANLIB -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: Need a teTeX-beta maintainer
Nicholas Wourms <[EMAIL PROTECTED]> writes: >>Jerome BENOIT no longer has the time to maintain the tetex-beta package. >> >>Any volunteers? >> >>Many thanks to Jerome for his efforts over the last 1+ years. >> > Since Jan Nieuwenhuizen already is already maintaining the cygwin > teTeX-texmf TDS tree and lillypod depends on teTeX-bin to operate, it > would make sense (to me) for Jan to be the teTeX-bin maintainer. > There is no need to have 2 people maintaining parts of a whole > package. Of course, whether or not Jan wants to do this is another > story... What do you say Jan? It makes some kind of sense. But I already made another vague promise (netpbm) that I haven't kept until now. This moring after reading Christopher's mail, I downloaded tetex-beta and latest sources to see if I could painlessly take over. I spent a good hour poking around, but I found that: * tetex isn't prepared for --srcdir builds (annoying) * tetex isn't prepared for cross builds (showstopper) * Jerome's Cygwin fixes have still not found their way upstream * Jerome's Cygwin patch isn't prepared for --srcdir builds So... I'll promise to take a look at it, because I really like to have a good tetex package in Cygwin. But, I can't promise to take it over yet, as I don't run Windows (and thus also no cygwin). If I can get the beast to cross build, and get it tested, I may step forward to be the maintainer. Greetings, Jan. Btw: I've been putting quite some time in getting a fine guile release to cross build for Cygwin, because this has a high priority for me. But as yet I can't get a shared version linked. It seems I need the latest autotools from cygwin, but I need them as cross build tools. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: Need a teTeX-beta maintainer
Nicholas Wourms <[EMAIL PROTECTED]> writes: > Perhaps, if you have a copy of windows kicking around, you might try > VMware? I've even heard rumors that someone got it running under Wine. I've got access to a machine that I can use for light testing, now and then, but no spare copy of windows, or vmware, ftm. > Pretty much all of Chuck's updates to libtool have been pushed > upstream starting about a week or two ago. I believe the same can be > said for the other autotools. Ok, that's good to hear. > You'll probably want to get the new gettext/iconv as well. I'd > reccommend getting HEAD CVS sources of libtool and autoconf, plus > the automake-1.6.2 releases. And that's a smart suggestion, in that case. I'll try that. Greetings, Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
libtool-CVS and Cygwin [WAS: Need a teTeX-beta maintainer]
Nicholas Wourms <[EMAIL PROTECTED]> writes: >>>Btw: I've been putting quite some time in getting a fine guile release >>> to cross build for Cygwin, because this has a high priority for >>> me. But as yet I can't get a shared version linked. It seems I >>> need the latest autotools from cygwin, but I need them as cross >>> build tools. >>> > Pretty much all of Chuck's updates to libtool have been pushed > upstream starting about a week or two ago. I believe the same can be > said for the other autotools. You'll probably want to get the new > gettext/iconv as well. I'd reccommend getting HEAD CVS sources of > libtool and autoconf, plus the automake-1.6.2 releases. Ok. This bit of positive info was all I needed to get going again. When I get this to work for guile, it will probably work for tetex-beta too. So. Today I spent making another Guile patch to get it compiled for Cygwin, and to fix cross building issues that were introduced during Guile's 1.5 development cycle. I started off getting autoconf, automake and libtool from CVS 1). Eventually, I succeeded in cleanly cross-building a static version of Guile, but I still can't get the shared version to link. Here's the error that I get: /bin/sh ../libtool --mode=link gcc -I/home/cygwin/cygwin-1.3.10/usr/include -L/home/cygwin/cygwin-1.3.10/usr/lib -L/home/cygwin/cygwin-1.3.10/usr/lib/w32api -L/home/cygwin/cygwin-1.3.10/usr/bin -O2 -g -Wall -Wmissing-prototypes -o guile.exe -dlpreopen force guile.o libguile.la -lm libtool: link: not configured to extract global symbols from dlpreopened files gcc -I/home/cygwin/cygwin-1.3.10/usr/include -O2 -g -Wall -Wmissing-prototypes -o guile.exe guile.o -L/home/cygwin/cygwin-1.3.10/usr/lib -L/home/cygwin/cygwin-1.3.10/usr/lib/w32api -L/home/cygwin/cygwin-1.3.10/usr/bin ./.libs/libguile.a /home/fred/cvs/guile/cygwin/libltdl/.libs/libltdl.a guile.o: In function `main': /home/fred/cvs/guile/cygwin/libguile/../../guile-core-1.6/libguile/guile.c:90: undefined reference to `lt_preloaded_symbols' Libtool complains about not being configured correctly, but libtool's ./configure script, nor guile's do offer this option, and it seems that Google is not much of a help. Who is supposed to provide this symbol, or how do I avoid needing it? The patch that I used to compile Guile is attached. David, how did you get round this problem? I would very much appreciate any insight into this. Greetings, Jan. *) Autoconf-CVS is a bit broken, in that it only works if Libtool is installed under the same prefix: installing updates of packages as I tend to do, with prefixes like: ~/usr/pkg/autoconf-cvs ~/usr/pkg/libtool-cvs won't work; you'll get the cryptic error: macro `AM_PROG_LIBTOOL' not found in library Index: ChangeLog === RCS file: /cvsroot/guile/guile/guile-core/ChangeLog,v retrieving revision 1.281.2.72 diff -p -u -r1.281.2.72 ChangeLog --- ChangeLog 6 May 2002 19:15:04 - 1.281.2.72 +++ ChangeLog 3 Jul 2002 15:40:16 - @@ -1,3 +1,13 @@ +2002-07-03 Jan Nieuwenhuizen <[EMAIL PROTECTED]> + + * autogen.sh: Only fix libltdl/configure.in if it exists. Current + libtool CVS does not need this fix. + + * configure.in (AC_LIBTOOL_WIN32_DLL): Add for shared Cygwin + build. + Add --with-cc-for-build option to re-enable cross building. + Add --with-guile-for-build option to re-enable cross building. + 2002-05-06 Marius Vollmer <[EMAIL PROTECTED]> * configure.in: Include before when Index: autogen.sh === RCS file: /cvsroot/guile/guile/guile-core/autogen.sh,v retrieving revision 1.11.2.10 diff -p -u -r1.11.2.10 autogen.sh --- autogen.sh 1 May 2002 21:05:26 - 1.11.2.10 +++ autogen.sh 3 Jul 2002 15:40:16 - @@ -47,11 +47,14 @@ $mscripts/render-bugs > BUGS rm -rf libltdl libtoolize --force --copy --automake --ltdl +# Fix older versions of libtool. # Make sure we use a ./configure.in compatible autoconf in ./libltdl/ -mv libltdl/configure.in libltdl/configure.tmp -echo 'AC_PREREQ(2.50)' > libltdl/configure.in -cat libltdl/configure.tmp >> libltdl/configure.in -rm libltdl/configure.tmp +if [ -f libltdl/configure.in ]; then + mv libltdl/configure.in libltdl/configure.tmp + echo 'AC_PREREQ(2.50)' > libltdl/configure.in + cat libltdl/configure.tmp >> libltdl/configure.in + rm libltdl/configure.tmp +fi ## autoheader Index: configure.in === RCS file: /cvsroot/guil
Re: libtool-CVS and Cygwin [WAS: Need a teTeX-beta maintainer]
Charles Wilson <[EMAIL PROTECTED]> writes: > Umm,, yeah -- all of the autotools must be installed under the same > prefix. > If you want to do it your way, you'd be better off installing all > three of your newly built packages under > "--prefix=~/usr/pkg/autotool-cvs/" So, yes, that's what I did. > Wacky configurations of the autotools are HARD to get right. Ok. Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Solved: libtool-CVS and Cygwin
Jan Nieuwenhuizen <[EMAIL PROTECTED]> writes: > Here's the error that I get: > > /bin/sh ../libtool --mode=link gcc -I/home/cygwin/cygwin-1.3.10/usr/include >-L/home/cygwin/cygwin-1.3.10/usr/lib -L/home/cygwin/cygwin-1.3.10/usr/lib/w32api >-L/home/cygwin/cygwin-1.3.10/usr/bin -O2 -g -Wall -Wmissing-prototypes -o >guile.exe -dlpreopen force guile.o libguile.la -lm > libtool: link: not configured to extract global symbols from dlpreopened files > gcc -I/home/cygwin/cygwin-1.3.10/usr/include -O2 -g -Wall -Wmissing-prototypes >-o guile.exe guile.o -L/home/cygwin/cygwin-1.3.10/usr/lib >-L/home/cygwin/cygwin-1.3.10/usr/lib/w32api -L/home/cygwin/cygwin-1.3.10/usr/bin >./.libs/libguile.a /home/fred/cvs/guile/cygwin/libltdl/.libs/libltdl.a > guile.o: In function `main': > /home/fred/cvs/guile/cygwin/libguile/../../guile-core-1.6/libguile/guile.c:90: >undefined reference to `lt_preloaded_symbols' > > Who is supposed to provide this symbol, or how do I avoid needing it? It so happens, that libtool gets distressed when the cross build loader is in PATH. Having the cross ld in PATH yields a ./libtool script that has: # Commands used to build and install a shared archive. archive_cmds="\$CC -o \$lib \$libobjs \$compiler_flags \\\`echo \\\"\$deplibs\\\" | sed -e 's/ -lc\$//'\\\` -link -dll~linknames=" which will obviously fail. ld says: cannot find -link So, after installing the cross binutils to be packaged, I got rid of it: mv -f $installroot/$CROSS_PREFIX/$TARGET_PLATFORM/bin/ld ld-in-path-breaks-libtool Then, you'll get a valid ./libtool script. However, to determine linkage for Cygwin, libtool needs LD to be set to the cross loader; and it also needs a C++ compiler that is capable of linking. So, here is what did it for me: CPPFLAGS="-I$PREFIX/include -L$PREFIX/lib -L$PREFIX/lib/w32api -L$PREFIX/bin" \ LD=$TARGET_PLATFORM-ld \ CC="gcc $CPPFLAGS $LDFLAGS" \ CXX="g++ $CPPFLAGS $LDFLAGS" \ ./configure --host=$TARGET_PLATFORM Guile packages coming up now, I'll look at tetex-beta after that (but no promises). Greetings, Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
ITP: Guile 1.5.6
Hi List, Last night, I've eventually succeeded in building guile-1.5.6, with shared object libraries for Cygwin. Guile version 1.5.6, is now available for testing at: http://lilypond.org/cygwin/tar/guile After a successful installation of guile (and libguile14), you should be able to run, eg, guile -c '(begin (write (string-append "hello: " (version) "\n")))' May we have your votes (and comments) please. Greetings, Jan. [there may be a working setup.ini at http://lilypond.org/cygwin] http://lilypond.org/cygwin/tar/guile/setup.hint sdesc: "The GNU extension language and Scheme interpreter (executable)" category: interpreters requires: cygwin libguile14 ldesc: "The GNU extension language and Scheme interpreter (executable) Guile, the GNU Ubiquitous Intelligent Language for Extension, is a scheme implementation designed for real world programming, supporting a rich Unix interface, a module system, and undergoing rapid development. `guile' is a scheme interpreter that can execute scheme scripts (with a #! line at the top of the file), or run as an inferior scheme process inside Emacs." http://lilypond.org/cygwin/tar/guile/guile-1.5.6-1.README http://lilypond.org/cygwin/tar/guile/guile-1.5.6-1-src.tar.bz2 http://lilypond.org/cygwin/tar/guile/guile-1.5.6-1.tar.bz2 === http://lilypond.org/cygwin/tar/guile/guile-doc/setup.hint sdesc: "The GNU extension language and Scheme interpreter (documentation)" category: doc requires: cygwin ldesc: "The GNU extension language and Scheme interpreter (documentation) This package contains the documentation for guile, including both a reference manual (via `info guile'), and a tutorial (via `info guile-tut')." http://lilypond.org/cygwin/tar/guile/guile-doc/guile-doc-1.5.6-1.tar.bz2 === http://lilypond.org/cygwin/tar/guile/libguile14/setup.hint sdesc: "The GNU extension language and Scheme interpreter (runtime libraries)" category: libs requires: cygwin ldesc: "The GNU extension language and Scheme interpreter (runtime libraries) Guile shared object libraries and the ice-9 scheme module. Guile is the GNU Ubiquitous Intelligent Language for Extension." http://lilypond.org/cygwin/tar/guile/libguile14/libguile14-1.5.6-1.tar.bz2 === http://lilypond.org/cygwin/tar/guile/libguile14-dev/setup.hint sdesc: "Development headers and static libraries for Guile." category: devel libs requires: cygwin ldesc: "Development headers and static libraries for Guile. `libguile.h' etc. C headers, aclocal macros, the `guile-snarf' and `guile-config' utilities, and static `libguile.a' libraries for Guile, the GNU Ubiquitous Intelligent Language for Extension." http://lilypond.org/cygwin/tar/guile/libguile14-dev/libguile14-dev-1.5.6-1.tar.bz2 -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: ITP: Guile 1.5.6
Charles Wilson <[EMAIL PROTECTED]> writes: > Well, the setup.hints for guile-doc, libguile14, and libguile14-dev > packages should all include an 'external-source: guide' line. Ah, ok, will do. I imagined upset would handle that kind of thing. > Also, the libguile14-dev package concerns me. It should probably be > called 'libguile14-devel' (not -dev) for consistency with other > packages. Consistency good. > Also, will libguile14-devel be able to peacefully coexist > with, say, libguile15-devel? Or should the -devel package be called > "guile-devel' instead, so that only the latest version of the > headers/statlibs/implibs are ever installed? > > To me, it sure looks like the latter is true: Yes, most probably. That's what Debian does, and cygwin.com/setup.html advises to look over there. In Debian, it's called libguile-dev. That combined with the example of libnetpmb10-dev[el] (ahum), led me to choose libguileX-dev. > So, this package should probably be >guile-devel > NOT >libguile14-dev Hmm, I'd say maybe libguile-dev, but I don't care too much? Anyone else feels like arguing? > There are also four bigger problems: > > 1) In libguile14-dev (guile-devel), these files: > usr/lib/libguile-srfi-srfi-13-14-lt-.a > usr/lib/libguile-srfi-srfi-4-lt-.a [..] > I'm almost positive that something is going terribly wrong here. > Those names just do NOT look right. Hmm, they look odd indeed. I'm sorry to let that slip. I'm so very much not charmed by automake and libtool. I'll have to investigate. (..) Turns out that I goofed, trying to fix a build problem by transplanting Makfile.am from CVS. > 2) The import libs should be in the -devel package, not the runtime > package. Ok. > 3) What's with the sticky bit on the directories within the archives? > Is that kosher? That's probably an artifact of my installation over here. Will fix that too. > 4) guile.m4 is in the wrong place, and in the wrong package. > Currently, it is in /usr/aclocal and is part of the libguile14 > package. It should be installed into /usr/SHARE/aclocal/ and should > be part of the 'libguile14-dev'=='guile-devel' package. Ok. Thank you very much for your detailed report. I should really have caught some of these things before releasing, but I've been waiting for this quite some time. > P.S. However, I do think that guile is a worthwhile addition to the > cygwin distribution... Thanks, Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: ITP: Guile 1.5.6
Charles Wilson <[EMAIL PROTECTED]> writes: > Correct. libnetpbm10-devel is wrong. It should be netpbm-devel (or > maybe libnetpbm-devel) Thanks (but I'll leave that change up to > you. ) :) >> Hmm, I'd say maybe libguile-dev, but I don't care too much? Anyone >> else feels like arguing? > > whatever-devEL. Consistency good. Arg. Typo, surEL. >> (..) Turns out that I goofed, trying to fix a build problem by >> transplanting Makfile.am from CVS. > > Mebbe. Fixed, now they're: usr/lib/libguile-srfi-srfi-13-14.dll.a usr/lib/libguile-srfi-srfi-4.a etc, just like on linux. Still strange, the ddouble srfi. Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: ITP: Guile 1.5.6
Nicholas Wourms <[EMAIL PROTECTED]> writes: > I'm sure that Chuck meant to say 'external-source: guile' Sure. > Now, as for building from source, the script included in the source > package is not a valid Cygwin script. It seems to be a > cross-compilation script. Yes, it is. To avoid confusion, I'll rename those to cross-guile-1.5.6-1.sh, for reference, and try my best at: > Would it be possible to adapt the generic > build script from the package building page? You're actually *developing* on Windows? Amazing. Anyway, it should all be rather staightforwardly untar patch ./configure make all install apart from the sub-package splitting, which already is a shell script. Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: ITP: Guile 1.5.6
Nicholas Wourms <[EMAIL PROTECTED]> writes: > The config.site doesn't seem right, like not detecting libintl. Hmm. It maybe even is, as see that I didn't install gettext et al. I'll look into this. > The new gettext (libintl) requires -lintl and -liconv to properly > link. Ok. > Also, it seems like you were having trouble with libtool dependency > support. I recommend deleting "depcomp install-sh mkinstalldirs > missing ..." before running running automake like this: > > automake --add-missing --copy --include-deps Ok, haven't look at dependencies. I was so glad it linked, at last :-) > It might be worth your while to briefly pop on that windows machine to > run configure under the "real" deal. That way you can be sure that > config.site has the proper variables. However, the autotools are > supposed to work on cross builds as well, by detecting support in the > cross directories... > > Before you generate a patch, make sure that you remove the > side-effects of the new autotools. The specific example is the > autom4te.cache dir, which doesn't need to be distributed. Ok, I'll have a look at the patch. My 'own' patch doesn't include any generated files, of course, but the scripts generate the diff, so that I'm sure it's correct (and does include an updated ./configure etc.) Thanks, Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: ITP: Guile 1.5.6
Nicholas Wourms <[EMAIL PROTECTED]> writes: >> The libintl is built from gettext, and the libintl-0.nn.nn package >> only contains runtime libraries. The import libraries are in >> gettext-0.11.2-2. When configure is checking for libintl, it wants >> the /lib/libintl(.dll)a import library. Here is what you need: >> >> 1)gettext-0.11.2-2 >> 2)gettext-devel-0.11.2-2 >> 3)libiconv-1.8-2 >> >> Cheers, >> Nicholas >> > Permit me to further clarify: > "When configure is checking for libintl, it wants the > /lib/libintl(.dll)a import library." Ok. But (nitpick) shouldn't those be in either libintlX, or in gettext-devel? I didn't imagine they would be in gettext, so I didn't even look there... Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: ITP: Guile 1.5.6
Nicholas Wourms <[EMAIL PROTECTED]> writes:
>> You're actually *developing* on Windows? Amazing.
> Yes, developing under Cygwin is a pleasure, a far cry from using
> command.com. It is almost to the point of being transparent from a
> linux developer's perspective. As we speak, I am currently running
> OpenBox on X11 in another window, in which I am looking at your
> package through an rxvt terminal. Cygwin isn't just a dll anymore,
> it's becoming a full-fledged OS now. Heck, it even has a /proc and
> /dev! The point is that I prefer to think I am developing inside
> Cygwin, not Windows... There is a difference.
Sure, Cygwin is great, and gets better all the time. If there's no
alternative and you must use Windows, Cygwin makes life bearable
(email without a mouse!). At least, that was my experience, some
three years, and I'm still very impressed by the progress Cygwin
makes.
Otoh, any 'reasons' for not replacing Windows by Linux get less valid
all the time too. And using Windows (even when mostly seen through
Cygwin), just 'feels' a bit awkward to me; it's as if Microsoft is in
control of your pc, instead of you. You're still stuck with the
irritating unconfigurable, unprogrammable Window's window manager,
hopeless Windows' device access/control (keyboard, mouse, disks,
printer), endless CRLF issues with Windows programs, and you have to
cope with Windows all-gui administration stuff. How do you manage?
Maybe I'm just spoiled.
Some of these things may even get fixed before too long, if the window
manager can be replaced, explorer can be dropped, and there's rootless
X, and a Cygwin Emacs... dreaming on ... and learning native Windows
programs about Cygwin paths and real cut and paste, by using some DLLs
from WINE. Did I miss any obvious important or impossible wishes?
> Ok, but this is *NOT* what the readme says. It tells people to run
> the script.
Hmm, yes. I've changed the readme text a bit, and included a native
Cygwin script. In -2 it still had a silly bug, but that's fixed for
the upcoming (and hopefully to be released) -3.
Greetings,
Jan.
#!/bin/sh
set -x
# Generic Cygwin build script -- modified for guile-1.5.6
# Jan Nieuwenhuizen <[EMAIL PROTECTED]>
#
# Note: guile-1.5.6 has not been built using this script,
# but rather using the cross build scripts at:
#
# http://lilypond.org/cygwin/cygwin-cross.tar.gz
#
# that process has been captured in cross-guile-1.5.6-2.sh
#
# TODO:
#
# * Shell scripts should start with: set -e
# * More generic sub-package handling
# find out where the build script is located
tdir=`echo "$0" | sed 's%[\\/][^\\/][^\\/]*$%%'`
test "x$tdir" = "x$0" && tdir=.
scriptdir=`cd $tdir; pwd`
# find src directory.
# If scriptdir ends in SPECS, then topdir is $scriptdir/..
# If scriptdir ends in CYGWIN-PATCHES, then topdir is $scriptdir/../..
# Otherwise, we assume that topdir = scriptdir
topdir1=`echo ${scriptdir} | sed 's%/SPECS$%%'`
topdir2=`echo ${scriptdir} | sed 's%/CYGWIN-PATCHES$%%'`
if [ "x$topdir1" != "x$scriptdir" ] ; then # SPECS
topdir=`cd ${scriptdir}/..; pwd`
else
if [ "x$topdir2" != "x$scriptdir" ] ; then # CYGWIN-PATCHES
topdir=`cd ${scriptdir}/../..; pwd`
else
topdir=`cd ${scriptdir}; pwd`
fi
fi
tscriptname=`basename $0 .sh`
export PKG=`echo $tscriptname | sed -e 's/\-[^\-]*\-[^\-]*$//'`
export VER=`echo $tscriptname | sed -e 's/^[^\-]*\-//' -e 's/\-[^\-]*$//'`
export REL=`echo $tscriptname | sed -e 's/^[^\-]*\-[^\-]*\-//'`
export FULLPKG=${PKG}-${VER}-${REL}
# if the orig src package is bzip2'ed, remember to
# change 'z' to 'j' in the 'tar xvzf' commands in the
# prep) and mkpatch) sections
export src_orig_pkg_name=${FULLPKG}-orig.tar.bz2
export src_pkg_name=${FULLPKG}-src.tar.bz2
export src_patch_name=${FULLPKG}.patch
export bin_pkg_name=${FULLPKG}.tar.bz2
export src_orig_pkg=${topdir}/${src_orig_pkg_name}
export src_pkg=${topdir}/${src_pkg_name}
export src_patch=${topdir}/${src_patch_name}
export bin_pkg=${topdir}/${bin_pkg_name}
export srcdir=${topdir}/${PKG}-${VER}
export objdir=${srcdir}/.build
export instdir=${srcdir}/.inst
export srcinstdir=${srcdir}/.sinst
export checkfile=${topdir}/${FULLPKG}.check
# run on
host=`gcc -dumpmachine`
# if this package creates binaries, they run on
target=$host
prefix=/usr
sysconfdir=/etc
MY_CFLAGS="-O2 -g"
MY_LDFLAGS=
mkdirs() {
(cd ${topdir} && \
mkdir -p ${objdir} && \
mkdir -p ${instdir} && \
mkdir -p ${srcinstdir} )
}
prep() {
(cd ${topdir} && \
tar xvjf ${src_orig_pkg} ; \
cd ${topdir}/$PKG-$VER && \
patch -p0 < ${src_patch} \
&& mkdirs )
}
c
Re: ITP: Guile 1.5.6
Charles Wilson <[EMAIL PROTECTED]> writes: > Yes, ordinarily you would be correct (just like you were earlier today > vis a vis netpbm ). However, the gettext package was split up in a > weird way, based on suggestions from Bruno Haible, the "real" GNU > gettext maintainer. Ok. [Snip very useful info] > Sorry for the confusion. :-) And thanks for the explanation. I just thought, it would be good to have this info in gettext-devel or libintl* package /usr/doc/gettext/, and maybe a hint of this in some setup.hint file? Greetings, Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
mknetrel for president
Hi Chris [and other mknetrel hackers],
Today, I had a look at mknetrel 1). I think it's great, and it indeed
looks a bit like the cygwin-cross tools 2).
A very short overview.
mknetrel:
* creation of cygwin packages only, by cross building on linux.
* set of functions for each stage (configure, make, install) etc,
and between stages.
* each package can override any of these functions with its own.
* configure, build, package src and binary package.
* rather simple, specific and lightweight.
cygwin-cross:
* optionally download latest source version.
* setup (configure, build, install, package) cross building environment.
* creation of cygwin packages, by cross building on linux.
* set of functions for each stage (configure, make, install) etc.
* each stage of each package can be overridden by using a more
specific shell snippet
* configure, build, package src and binary package.
* recreate actual (think autotools etc), patch by diffing against
pristine sources.
* create [cross] build script that has effectively been used, by
glueing all shell snippets together.
* mirror essential parts of cygwin distro.
* generate setup.ini.
* bit barok (lots of history in it), flexible and configurable.
Looking at mknetrel, there are two things that I really miss from my
self-centered pov:
* setting up the cross building environment.
* downloading, untarring and patching of latest, pristine sources (for
stuff that hasn't yet gone into Cygwin), and
Now, I seem to remember that Chris posted a real easy way to setup the
cross building environment from CVS [but I can't seem to find that
now], and the other feature I added to mknetrel today.
Anyway, all in all, there's not too much difference, so I think that
mknetrel looks a good way to go, esp. because it's simple and contains
a lot less legacy stuff, and mostly because it's silly to keep
duplicating efforts.
I've done some random qad hacking at mknetrel, as if it were my own,
to enable packaging guile with it; patch is attached.
What I'd like to add also, is the auto-generation of a Cygwin build
script. That should be not too hard; fix mknetrel up for native
Cygwin builds, move all functions out of mknetrel, and replace
mknetrel's command line parsing with a simple 'what=$base' statement
or so.
Chris, I don't expect you to apply this patch like it is, but am rather
posting it to get some comments about what you think and where
to go, eg, I can imagine that you want to keep the `importing' of new
sources in a separate tool. Also, part of the package splitting
options I added may be a bit too simplistic, and too specific for
guile; and you may want to move that back into extra/guile.
Greetings,
Jan.
1) cvs -d:pserver:[EMAIL PROTECTED]:/cvs/cygwin-apps co mknetrel
2) http://lilypond.org/cygwin/cygwin-cross.tar.gz
diff -purNX .cvsignore ../mknetrel.cvs/.cvsignore ./.cvsignore
--- ../mknetrel.cvs/.cvsignore Thu Jan 1 01:00:00 1970
+++ ./.cvsignoreMon Jul 8 02:54:17 2002
@@ -0,0 +1,5 @@
+CVS
+*~
+#*
+.#*
+.bash_mknetrel
diff -purNX .cvsignore ../mknetrel.cvs/ChangeLog ./ChangeLog
--- ../mknetrel.cvs/ChangeLog Mon Jul 8 01:41:27 2002
+++ ./ChangeLog Mon Jul 8 02:25:43 2002
@@ -1,3 +1,33 @@
+2002-07-08 Jan Nieuwenhuizen <[EMAIL PROTECTED]>
+
+ * bin/mknetrel (lib_name):
+ (devel_name):
+ (doc_name): New function: Return name of subpackage.
+ (lib_split):
+ (devel_split):
+ (doc_split): New function: Attempt at splitting a subpacke by name.
+ (domkdist): Support for packaging subpackages.
+
+2002-07-07 Jan Nieuwenhuizen <[EMAIL PROTECTED]>
+
+ * patch/guile-1.5.6-3.patch: New file. The patch directory
+ contains patches for packages that have not yet been officially
+ packaged for Cygwin, but can probably be built.
+
+ * bin/mknetrel: Add -f function to force downloading. Adapt usage
+ message.
+ (die):
+ (drop):
+ (tarball_sort):
+ (split):
+ (setvars2):
+ (download):
+ (untar): New function. These functions are taken and adapted from
+ the cygwin-cross tools and support downloading of latest pristine
+ tarball, untarring and patching.
+
+ * extra/guile: New file.
+
2002-07-06 Christopher Faylor <[EMAIL PROTECTED]>
* mknetrel (doconfig): Export CC_FOR_TARGET and CXX_FOR_TARGET.
diff -purNX .cvsignore ../mknetrel.cvs/bin/mknetrel ./bin/mknetrel
--- ../mknetrel.cvs/bin/mknetrelSun Jul 7 04:49:10 2002
+++ ./bin/mknetrel Mon Jul 8 03:05:38 2002
@@ -1,54 +1,120 @@
#!/bin/bash
+# Exit upon error
+set -e
+
+# Interactive shell with state of bash at exit upon failure
+# todo: optional 'dodrop' etc.
+function drop ()
+{
+[ "$?" -eq 0 ] && trap - 0 9 15 && exit 0 || true
+echo "$0: dropping
Re: mknetrel for president
Christopher Faylor <[EMAIL PROTECTED]> writes: >> * creation of cygwin packages only, by cross building on linux. > > It's not just for cross building on linux. It can be used anywhere. Sure, that was an oversight. >> * setting up the cross building environment. > > There should be little, if any cross build environment to set up. You > either have the cross compilers or you don't. > I don't know what you mean by "cross build environment". If you want > to build on linux you have to build a compiler and a linker. Ok, but for Cygwin that used to be quite hairy and tricky at times. It's easy to find yourself having a cross compiler that doesn't work. A set of simple instructions, preferrably also documented in a script, that configure, build and install these for you can be a great help? > Also the purpose of mknetrel is to absolutely, positively minimize > the amount of patching that is required. I've only found the need > to actually patch a few packages, Yes, that's why I say it looks like my cross scripts, for well behaved packages all you should have to do is grab the latest tarball. Possibly maybe rerun autotools. >>I've done some random qad hacking at mknetrel, as if it were my own, >>to enable packaging guile with it; patch is attached. > > If you want to submit these as individually contained patches, I'll take > a look at them. Otherwise, there is the generic problem with monolithic > patches. Sure, but how does this fit in with your >> * downloading, untarring and patching of latest, pristine sources (for >>stuff that hasn't yet gone into Cygwin), and > > One tool, one job. Hmm. Where did I hear that before? comment? I was hoping to get a rough sense of direction on some of these issues: * fixes, doco (always good) * better latest version detection? * subpackage splitting (good, maybe needs work?) * downloading, untarring patching good?/no way? -> try moving to ./bin/pimport and I didn't want to take your time *before* showing some actual code. The patch is real big because it contains the Guile patch, but it's not that unreadable? Anyway, in the meantime I'll try to split up the patch and feed you small bits. Greetings, Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: mknetrel for president
Anurag Sharma <[EMAIL PROTECTED]> writes: > Where can I find "Jan's scripts for building a cross-compiler", as > mentioned below by Nicholas. > I would really appreciate any help on this. http://lilypond.org/cygwin/cygwin-cross.tar.gz Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
[PATCH]: mknetrel builds Guile #1: init
Hi,
In my attempt to reduce duplication of effort, I'm looking to
deprecate my cygwin-cross tools, and add functionality that's missing
to build Guile, to mknetrel.
I've broken down my patch of last Sunday, like you requested. I've
left out the 'download and untar latest' stuff for now.
Patches should be applied in order.
Greetings,
Jan.
- add README
- a few init fixes to get mknetrel going
diff -purNX .cvsignore ../mknetrel.jcn0.cvs/.cvsignore ./.cvsignore
--- ../mknetrel.jcn0.cvs/.cvsignore Thu Jan 1 01:00:00 1970
+++ ./.cvsignoreMon Jul 8 15:42:06 2002
@@ -0,0 +1,4 @@
+CVS
+*~
+#*
+.#*
diff -purNX .cvsignore ../mknetrel.jcn0.cvs/ChangeLog ./ChangeLog
--- ../mknetrel.jcn0.cvs/ChangeLog Sun Jul 7 04:49:09 2002
+++ ./ChangeLog Tue Jul 9 01:17:39 2002
@@ -1,3 +1,18 @@
+2002-07-08 Jan Nieuwenhuizen <[EMAIL PROTECTED]>
+
+ * VERSION mknetrel.jcn1.init
+
+ * .cvsignore: New file.
+
+ * README: New file.
+
+ * bin/mknetrel:
+ (read_user_config): Add cygwin_root as configurable var.
+ (setvars): Bugfix: $extra lives in mknetrel source dir.
+ (setup): Use $cygwin_root (previously: /cygwin).
+ Add -h option to display usage.
+ (usage): More standardized.
+
2002-07-06 Christopher Faylor <[EMAIL PROTECTED]>
* mknetrel (doconfig): Export CC_FOR_TARGET and CXX_FOR_TARGET.
diff -purNX .cvsignore ../mknetrel.jcn0.cvs/README ./README
--- ../mknetrel.jcn0.cvs/README Thu Jan 1 01:00:00 1970
+++ ./READMEMon Jul 8 23:59:00 2002
@@ -0,0 +1,67 @@
+This is mknetrel, a collection of shell scripts to build Cygwin
+packages. Mknetrel can be used natively on Cygwin, or in a cross
+build environment (the default is cross building on GNU/Linux).
+
+Get the latest version here:
+ cvs -d:pserver:[EMAIL PROTECTED]:/cvs/cygwin-apps co mknetrel
+
+To use mknetrel, you must setup a cross build environment. See the
+Cygwin mailing list archives for more info on this. When porting a
+new package to Cygwin, it is advisable to install latest CVS versions
+of autoconf, automake and libtool.
+
+You also need Cygnus' Cygwin package, 1.3.10 or newer, and w32api from
+a mirror of:
+
+ ftp://cygwin.com/pub/cygwin/release
+ http://cygwin.com/mirrors.html
+
+and, depending on which package you want to build, other library and
+development packages from Cygwin, such as: zlib gettext libintl2
+libiconv2 jpeg libpng10 libpng10-devel python tetex tiff zlib.
+
+This can be automated by running the cygwin-cross tools from:
+
+ http://lilypond.org/cygwin/cygwin-cross.tar.gz
+
+[doco how to do this from cygwin cvs, deprecate cygwin-cross tools.]
+
+Mknetrel reads config vars from your `~/.mknetrel'. Here's what I
+use:
+
+cygwin_root=/home/cygwin
+netrel_root=$cygwin_root/netrel
+
+Then, you run mknetrel as:
+
+ wget -P/tmp ftp://sunsite.auc.dk/mirrors/cygwin/release/ed/ed-*-1-src.*bz2
+ rm -rf /home/cygwin/netrel/src/ed-*
+ mkdir -p /home/cygwin/netrel/src && cd /home/cygwin/netrel/src
+ tar xjf /tmp/ed*bz2
+ cd -
+ ./bin/mknetrel ed
+
+to build the ed package, or do
+
+ ./bin/mknetrel -h
+
+for a short help summary.
+
+
+If you are not using mknetrel on GNU/Linux, you'll want to add:
+something like this in your ~/.mknetrel:
+
+build_cxx='g++'
+build_cc='gcc'
+build_ranlib='ranlib'
+build_dllwrap='dllwrap'
+build_ar='ar'
+build_nm='nm'
+build_strip='strip'
+build_config_opts=''
+
+(this will probably be fixed in a later version).
+
+Send bug reports and comments on mknetrel to: [EMAIL PROTECTED]
+This is a subscribers-only mailing list, so you'll need to subscribe
+first. Please do not email the authors directly.
diff -purNX .cvsignore ../mknetrel.jcn0.cvs/bin/mknetrel ./bin/mknetrel
--- ../mknetrel.jcn0.cvs/bin/mknetrel Sun Jul 7 04:49:10 2002
+++ ./bin/mknetrel Tue Jul 9 01:06:32 2002
@@ -3,6 +3,7 @@
read_user_config() {
[ -r "$HOME/.mknetrel" ] && . "$HOME/.mknetrel"
: ${netrel_root=/netrel}
+: ${cygwin_root=/cygwin}
: ${build_cxx='i686-pc-cygwin-g++'}
: ${build_cc='i686-pc-cygwin-gcc'}
: ${build_ranlib='i686-pc-cygwin-ranlib'}
@@ -14,6 +15,7 @@ read_user_config() {
}
setvars() {
+mknetrel=$(cd $(dirname $0)/..; pwd)
cd $netrel_root || exit 1
here=`pwd`
if newest; then
@@ -42,7 +44,7 @@ setvars() {
build=$here/build/$package
inst=$here/inst/$package
uploads=$here/uploads
-extra=$here/extra
+extra=$mknetrel/extra
tarstem=$uploads/$package
src_exclude='>>>InExPlIbAbLe<<<'
}
@@ -74,8 +76,8 @@ setup() {
read_user_config
clean=false
opt="-O2"
-export knownpath='/cygwin/bin:'
-while getopts 'itbc
[PATCH]: mknetrel builds Guile #2: debug
- add debugging feature: drop to shell upon failure
diff -purNX .cvsignore ../mknetrel.jcn1.init/.cvsignore ./.cvsignore
--- ../mknetrel.jcn1.init/.cvsignoreMon Jul 8 15:42:06 2002
+++ ./.cvsignoreMon Jul 8 16:04:09 2002
@@ -2,3 +2,4 @@ CVS
*~
#*
.#*
+.bash_mknetrel
diff -purNX .cvsignore ../mknetrel.jcn1.init/ChangeLog ./ChangeLog
--- ../mknetrel.jcn1.init/ChangeLog Tue Jul 9 01:17:39 2002
+++ ./ChangeLog Tue Jul 9 01:17:29 2002
@@ -1,5 +1,16 @@
2002-07-08 Jan Nieuwenhuizen <[EMAIL PROTECTED]>
+ * VERSION mknetrel.jcn2.debug
+
+ * .cvsignore: Add .bash_mknetrel.
+
+ * bin/mknetrel (drop): New funtion. Add trap command, to invoke
+ drop () upon unsuccessful exit, so that user make investigate at
+ the spot what went wrong. To test this, make a function such as
+ postconfig () or postbuild () return an error.
+ (usage): Don't drop to shell. Use exit value 2, commonly for
+ usage errors.
+
* VERSION mknetrel.jcn1.init
* .cvsignore: New file.
diff -purNX .cvsignore ../mknetrel.jcn1.init/bin/mknetrel ./bin/mknetrel
--- ../mknetrel.jcn1.init/bin/mknetrel Tue Jul 9 01:06:32 2002
+++ ./bin/mknetrel Tue Jul 9 01:07:05 2002
@@ -14,6 +14,23 @@ read_user_config() {
: ${build_config_opts='--build=i686-pc-linux --host=i686-pc-cygwin
--target=i686-pc-cygwin'}
}
+# Interactive shell with state of bash at exit upon failure
+drop ()
+{
+[ "$?" -eq 0 ] && trap - 0 9 15 && exit 0 || true
+echo "$0: dropping to shell..."
+set | sed -e 's/^\(BASH_VERSINFO=\)/#\1/' \
+ -e 's/^\(EUID=\)/#\1/' \
+ -e 's/^\(PPID=\)/#\1/' \
+ -e 's/^\(SHELLOPTS=\)/#\1/' \
+ -e 's/^\(UID=\)/#\1/' > .bash_mknetrel
+echo "PS1='mknetrel-debug \w$ '" >> .bash_mknetrel
+exec bash --rcfile .bash_mknetrel
+}
+
+# Call drop at exit
+trap drop 0 9 15
+
setvars() {
mknetrel=$(cd $(dirname $0)/..; pwd)
cd $netrel_root || exit 1
@@ -329,7 +346,7 @@ Options:
Available packages:
$(cd $(dirname $0)/../extra && echo *[a-z])
" 1>&2
-exit 1
+trap - 0 9 15 && exit 2
}
rest() {
--
Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org
[PATCH]: mknetrel builds Guile #3: libtool
- fixes and preparations for building with libtool
diff -purNX .cvsignore ../mknetrel.jcn2.debug/ChangeLog ./ChangeLog
--- ../mknetrel.jcn2.debug/ChangeLogTue Jul 9 01:17:29 2002
+++ ./ChangeLog Tue Jul 9 01:17:09 2002
@@ -1,5 +1,15 @@
2002-07-08 Jan Nieuwenhuizen <[EMAIL PROTECTED]>
+ * VERSION mknetrel.jcn3.libtool
+
+ * README: Add build_ld in description on ~/.mknetrel.
+
+ * bin/mknetrel (read_user_config): Add build_ld as configurable
+ var.
+ (doconfig): Set LD to help libtool detect that dlopen/dlpreopen
+ work. Move preconfig call up, so that $build_config_opts may be
+ overridden.
+
* VERSION mknetrel.jcn2.debug
* .cvsignore: Add .bash_mknetrel.
diff -purNX .cvsignore ../mknetrel.jcn2.debug/README ./README
--- ../mknetrel.jcn2.debug/README Mon Jul 8 23:59:14 2002
+++ ./READMEMon Jul 8 23:59:23 2002
@@ -53,6 +53,7 @@ something like this in your ~/.mknetrel:
build_cxx='g++'
build_cc='gcc'
+build_ld='ld'
build_ranlib='ranlib'
build_dllwrap='dllwrap'
build_ar='ar'
diff -purNX .cvsignore ../mknetrel.jcn2.debug/bin/mknetrel ./bin/mknetrel
--- ../mknetrel.jcn2.debug/bin/mknetrel Tue Jul 9 01:07:05 2002
+++ ./bin/mknetrel Tue Jul 9 01:07:18 2002
@@ -6,6 +6,7 @@ read_user_config() {
: ${cygwin_root=/cygwin}
: ${build_cxx='i686-pc-cygwin-g++'}
: ${build_cc='i686-pc-cygwin-gcc'}
+: ${build_ld='i686-pc-cygwin-ld'}
: ${build_ranlib='i686-pc-cygwin-ranlib'}
: ${build_dllwrap='i686-pc-cygwin-dllwrap'}
: ${build_ar='i686-pc-cygwin-ar'}
@@ -162,9 +163,9 @@ mystrip() {
}
doconfig() {
-CONFIGOPTS="${build_config_opts} "'--enable-haifa --prefix=/usr
--exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib
--includedir=/nonexistent/include --libexecdir=/usr/sbin
--disable-version-specific-runtime-libs'
preconfig || exit 1
-CXX="${build_cxx}" CXX_FOR_TARGET="${build_cc}" CC="${build_cc}"
CC_FOR_TARGET="${build_cc}" GCC_FOR_TARGET="${build_cc}" RANLIB="${build_ranlib}"
DLLWRAP="${build_dllwrap}" AR="${build_ar}" NM="${build_nm}" $src/configure
$CONFIGOPTS || exit 1
+CONFIGOPTS="${build_config_opts} "'--enable-haifa --prefix=/usr
+--exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib
+--includedir=/nonexistent/include --libexecdir=/usr/sbin
+--disable-version-specific-runtime-libs'
+CXX="${build_cxx}" CXX_FOR_TARGET="${build_cc}" CC="${build_cc}"
+CC_FOR_TARGET="${build_cc}" GCC_FOR_TARGET="${build_cc}" LD="${build_ld}"
+RANLIB="${build_ranlib}" DLLWRAP="${build_dllwrap}" AR="${build_ar}" NM="${build_nm}"
+$src/configure $CONFIGOPTS || exit 1
postconfig || exit 1
}
--
Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org
[PATCH]: mknetrel builds Guile #4: genscript
- autogenerate cygwin build script: $package.sh
diff -purNX .cvsignore ../mknetrel.jcn3.libtool/ChangeLog ./ChangeLog
--- ../mknetrel.jcn3.libtool/ChangeLog Tue Jul 9 01:17:09 2002
+++ ./ChangeLog Tue Jul 9 01:16:46 2002
@@ -1,3 +1,14 @@
+2002-07-09 Jan Nieuwenhuizen <[EMAIL PROTECTED]>
+
+ * VERSION mknetrel.jcn4.genscript
+
+ * bin/mknetrel: Delay `main' for autobuild.
+ (parseopts): New function (previously second part
+ of setup ().
+ (setup): Remove option parsing.
+ (genscript): New function. Generate required Cygwin autobuild
+ script.
+
2002-07-08 Jan Nieuwenhuizen <[EMAIL PROTECTED]>
* VERSION mknetrel.jcn3.libtool
diff -purNX .cvsignore ../mknetrel.jcn3.libtool/bin/mknetrel ./bin/mknetrel
--- ../mknetrel.jcn3.libtool/bin/mknetrel Tue Jul 9 01:07:18 2002
+++ ./bin/mknetrel Tue Jul 9 01:13:17 2002
@@ -1,4 +1,5 @@
#!/bin/bash
+# mknetrel
read_user_config() {
[ -r "$HOME/.mknetrel" ] && . "$HOME/.mknetrel"
@@ -83,6 +84,7 @@ setup() {
preinstall() { :; }
postinstall() { :; }
prepackage() { :; }
+presplit() { :; }
prepath() { :; }
postpackage() { :; }
rebuild() { :; }
@@ -92,6 +94,9 @@ setup() {
verbose() { :; }
mkdist() { domkdist; }
read_user_config
+}
+
+parseopts () {
clean=false
opt="-O2"
export knownpath="$cygwin_root/bin:"
@@ -299,6 +304,58 @@ dousrstuff() {
hard2soft
}
+genscript () {
+script=$here/src/$package.sh
+cat < $script
+#!/bin/bash
+# $package.sh -- Automagically generated by $0.
+# Do not edit, changes will be lost.
+
+# we're autobuilding $package
+autogen=$package
+
+# in /usr/src
+netrel_root=/usr
+
+# natively on Cygwin
+build_cxx='g++'
+build_cc='gcc'
+build_ld='ld'
+build_ranlib='ranlib'
+build_dllwrap='dllwrap'
+build_ar='ar'
+build_nm='nm'
+build_strip='strip'
+build_config_opts=
+
+EOS
+
+cat $mknetrel/$0 >> $script
+
+cat <> $script
+
+setup
+
+newest () { return 1 }
+genscript () { :; }
+
+EOS2
+
+[ -r "$extra/$what" ] && cat $extra/$what >> $script
+
+cat <> $script
+
+parseopts ${@+"$@"} $base
+if background; then
+rest&
+else
+rest
+fi
+EOS3
+
+chmod 755 $script
+}
+
domkdist() {
#
# Fix up installation slightly
@@ -319,7 +376,11 @@ domkdist() {
cd $src/.. || exit 1
echo creating "$tarstem"-src.tar.bz2
-find $package_src/* -print -follow | egrep -v
'\.cvsignore|\.bak$|\.orig$|\.o$|~$|^.#|CVS|%redact|/tags$' | egrep -v "$src_exclude"
| sort | tar -T - --no-recursion -cjf "$tarstem"-src.tar.bz2
+
+# Generate required autobuild script
+genscript
+
+find $package_src/* $package.sh -print -follow | egrep -v
+'\.cvsignore|\.bak$|\.orig$|\.o$|~$|^.#|CVS|%redact|/tags$' | egrep -v "$src_exclude"
+| sort | tar -T - --no-recursion -cjf "$tarstem"-src.tar.bz2
postpackage
}
@@ -374,10 +435,17 @@ rest() {
fi
}
-setup ${@+"$@"}
+# Delay this when we're part of autobuild script
+if [ -z "$autogen" ]; then
+setup
+parseopts ${@+"$@"}
+if background; then
+ rest&
+else
+ rest
+fi
+# unreachable
+exit 1
+fi
-if background; then
-rest&
-else
-rest
-fi
+## End of mknetnel
--
Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org
[PATCH]: mknetrel builds Guile #5: split
- add funtionality to split into and build sub packages
diff -purNX .cvsignore ../mknetrel.jcn4.genscript/ChangeLog ./ChangeLog
--- ../mknetrel.jcn4.genscript/ChangeLogTue Jul 9 01:16:46 2002
+++ ./ChangeLog Tue Jul 9 01:19:07 2002
@@ -1,5 +1,23 @@
2002-07-09 Jan Nieuwenhuizen <[EMAIL PROTECTED]>
+ * VERSION mknetrel.jcn5.split
+
+ * bin/mknetrel (read_user_config): Add build_prefix as
+ configurable var.
+ (lib_name):
+ (devel_name):
+ (doc_name): New function: Return name of subpackage.
+ (lib_split):
+ (devel_split):
+ (doc_split): New function: Attempt at splitting a subpackage by
+ name.
+ (domkdist): Support for packaging subpackages. Splitting of a
+ package is controlled by a new variable $subpackages. To create
+ subpackages, it should contain the symbolic names of the
+ subpackages. Currently, the symbolic packages 'lib doc devel' are
+ supported.
+ (setup): Add empty presplit () implementation.
+
* VERSION mknetrel.jcn4.genscript
* bin/mknetrel: Delay `main' for autobuild.
diff -purNX .cvsignore ../mknetrel.jcn4.genscript/bin/mknetrel ./bin/mknetrel
--- ../mknetrel.jcn4.genscript/bin/mknetrel Tue Jul 9 01:13:17 2002
+++ ./bin/mknetrel Tue Jul 9 01:05:42 2002
@@ -14,6 +14,7 @@ read_user_config() {
: ${build_nm='i686-pc-cygwin-nm'}
: ${build_strip='i686-pc-cygwin-strip'}
: ${build_config_opts='--build=i686-pc-linux --host=i686-pc-cygwin
--target=i686-pc-cygwin'}
+: ${build_prefix=/usr}
}
# Interactive shell with state of bash at exit upon failure
@@ -356,6 +357,41 @@ EOS3
chmod 755 $script
}
+lib_name () {
+echo lib$base$sover
+}
+
+devel_name () {
+echo $base-devel
+}
+
+doc_name () {
+echo $base-doc
+}
+
+lib_split () {
+mkdir -p ./$build_prefix/bin || exit 1
+mv $inst/$build_prefix/bin/*.dll ./$build_prefix/bin
+mkdir -p ./$build_prefix/share || exit 1
+mv $inst/$build_prefix/share/$base ./$build_prefix/share
+}
+
+devel_split () {
+mkdir -p ./$build_prefix/bin || exit 1
+mv $inst/$build_prefix/bin/guile-* ./$build_prefix/bin
+mv $inst/$build_prefix/include ./$build_prefix/include
+mkdir -p ./$build_prefix/lib || exit 1
+mv $inst/$build_prefix/lib/*.a ./$build_prefix/lib
+mv $inst/$build_prefix/lib/*.la ./$build_prefix/lib
+mkdir -p ./$build_prefix/share || exit 1
+mv $inst/$build_prefix/share/aclocal ./$build_prefix/share
+}
+
+doc_split () {
+mkdir -p ./$build_prefix || exit 1
+mv $inst/$build_prefix/info ./$build_prefix
+}
+
domkdist() {
#
# Fix up installation slightly
@@ -365,15 +401,49 @@ domkdist() {
cd usr 2>/dev/null && dousrstuff
cd $inst || exit 1
-prepackage
-cd $inst || exit 1
+presplit
+for i in $subpackages; do
+ subname=$(${i}_name)
+rm -rf $inst-$i
+ mkdir -p $inst-$i || exit 1
+ cd $inst-$i
+ ${i}_split || exit 1
+done
+
#
# Make tar balls
#
+
+cd $inst || exit 1
+prepackage
+
+# The base package
echo creating $tarstem.tar.bz2
+cd $inst || exit 1
+
+# We need som standardization for these hint file names,
+# and we'll certainly will never get a directory named
+# CYGWIN-PATCHES merged upstream.
+# What about checking for `./cygwin/changelog', or something that
+# should most probably be unique?
+f=$src/CYGWIN-PATCHES/setup.hint test -r $f && cp $f $uploads/$base || true
+f=$src/CYGWIN-PATCHES/$base.hint test -r $f && cp $f $uploads/$base/setup.hint
+|| true
find * -print | sort | tar -T - --no-recursion -cjf $tarstem.tar.bz2
+# The sub packages
+for i in $subpackages; do
+ subname=$(${i}_name)
+ subload=$uploads/$subname
+ subtarstem=$subload/$subname-$ver
+ mkdir -p $subload || exit 1
+ echo creating $subtarstem.tar.bz2
+ f=$src/CYGWIN-PATCHES/$subname.hint test -r $f && cp $f $subload/setup.hint ||
+true
+ cd $inst-$i
+ find * -print | sort | tar -T - --no-recursion -cjf $subtarstem.tar.bz2
+done
+
+# The source package
cd $src/.. || exit 1
echo creating "$tarstem"-src.tar.bz2
--
Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org
[PATCH]: mknetrel builds Guile #6: Guile
- add extra/guile script
- add patch/guile-1.5.6-3.patch
diff -purNX .cvsignore ../mknetrel.jcn5.split/ChangeLog ./ChangeLog
--- ../mknetrel.jcn5.split/ChangeLogTue Jul 9 01:19:07 2002
+++ ./ChangeLog Tue Jul 9 01:20:44 2002
@@ -1,5 +1,12 @@
2002-07-09 Jan Nieuwenhuizen <[EMAIL PROTECTED]>
+ * VERSION mknetrel.jcn6.guile
+
+ * bin/mknetrel (setvars): New variable: patch.
+
+ * extra/guile:
+ * patch/guile: New file.
+
* VERSION mknetrel.jcn5.split
* bin/mknetrel (read_user_config): Add build_prefix as
diff -purNX .cvsignore ../mknetrel.jcn5.split/bin/mknetrel ./bin/mknetrel
--- ../mknetrel.jcn5.split/bin/mknetrel Tue Jul 9 01:05:42 2002
+++ ./bin/mknetrel Tue Jul 9 01:05:20 2002
@@ -65,6 +65,7 @@ setvars() {
inst=$here/inst/$package
uploads=$here/uploads
extra=$mknetrel/extra
+patch=$mknetrel/patch
tarstem=$uploads/$package
src_exclude='>>>InExPlIbAbLe<<<'
}
diff -purNX .cvsignore ../mknetrel.jcn5.split/extra/guile ./extra/guile
--- ../mknetrel.jcn5.split/extra/guile Thu Jan 1 01:00:00 1970
+++ ./extra/guile Tue Jul 9 01:28:04 2002
@@ -0,0 +1,179 @@
+# -*- shell-script -*-
+
+# Guile specific mknetrel overrides
+# To use this, do something like:
+cat >/dev/null <ftp://alpha.gnu.org/pub/gnu/guile/guile-1.5.6.tar.gz
+ # tar xzf /tmp/guile-1.5.6.tar.gz
+ wget -P/tmp
+ftp://lilypond.org/pub/LilyPond/cygwin/tar/guile/guile-1.5.6-*-orig.tar.bz2
+ rm -rf /home/cygwin/netrel/src/guile-*
+ mkdir -p /home/cygwin/netrel/src && cd /home/cygwin/netrel/src
+ tar xjf /tmp/guile-1.5.6-*orig.tar.bz2
+ mv guile-1.5.6 guile-1.5.6-3
+ cd -
+ ./bin/mknetrel -x guile
+
+EOC
+
+# Note that although mknetrel will package guile-1.5.6-3, the Cygwin
+# packages for guile-1.5.6-3 have not (yet) been generated with this
+# script, but rather with the cygwin-cross tools from:
+
+# http://lilypond.org/cygwin/cygwin-cross.tar.gz
+
+# This is still in the testing phase.
+
+
+
+
+# stable Guile releases: guile-1.4.1
+# archive=ftp://ftp.gnu.org/pub/gnu
+
+# development releases
+# archive=ftp://alpha.gnu.org/pub/gnu
+
+# alpha is off line...
+archive=$local_archive
+BUILD=3
+sover=14
+
+subpackages="lib devel doc"
+
+needdevoflags () {
+return 1
+}
+
+dodownload ()
+{
+_download $package*.tar.gz -orig$cygtargz
+}
+
+dopatchsrc () {
+cd $src
+patch -p1 < $patch/$package.patch
+aclocal
+rm -rf libltdl
+libtoolize --force --copy --automake --ltdl
+autoheader
+autoconf
+
+# automake --add-missing
+# Nicholas sez:
+
+rm -f depcomp install-sh mkinstalldirs missing # etc, must look
+automake --add-missing --copy --include-deps
+}
+
+# Move to mknetrel?
+patchsrc () {
+[ -r $patch/$package.patch -a ! -d $src/CYGWIN-PATCHES ] && dopatchsrc
+}
+
+# do I have a broken setup, do the Guile developers not know how to
+# write configure.in and Makefile.am, or are automake/libtool broken?
+preconfig () { # aka libtool_woes ()
+
+# Add to mknetrel?
+patchsrc
+
+cd $build || exit 1
+
+# What's this? docme
+# LIBS=`i686-pc-cygwin-gcc --print-file-name=binmode.o`
+# LIBS=`i686-pc-cygwin-gcc --print-file-name=textmode.o`
+# export LIBS
+
+# Help automake with confusing EXEEXT variable.
+# In our case, we actually have: BUILD_EXEXT= HOST_EXEEXT=.exe
+EXTRABUILDARGS="EXEEXT="
+EXTRAINSTALLARGS="EXEEXT="
+
+# Convince libtool that 'SED=' won't work.
+export SED=sed
+
+# Can't add these to CFLAGS/LDFLAGS, would end up in libguile.*
+# and thus show in guile-config script
+
+libtoolflags="-I$cygwin_prefix/include -L$cygwin_prefix/lib
+-L$cygwin_prefix/lib/w32api -L$cygwin_prefix/bin"
+# libtoolflags=$("$build_cc" -print-search-dirs | grep '^libraries:' | sed -e
+'s/^libraries: */ :/' -e 's/:/ -L/g' -e 's/ */ /g' -e 's/ *$//')
+guileflags="-L../libguile/.libs"
+build_cc="${build_cc} $libtoolflags $guileflags"
+build_cxx="${build_cxx} $libtoolflags $guileflags"
+
+# Fix libtool's -rpath detection
+export CC="${build_cc}"
+export CXX="${build_cxx}"
+
+# another libtool fix
+mkdir -p libguile/.libs
+
+# anyway, Libtool doesn't like it
+# libtool: link: cannot build libtool library `libguile.la' from non-libtool
+objects on this host: /home/cygwin/cygwin-1.3.10/usr/lib/textmode.o
+
+# Let's adhere to mkconfig connvention, but why not use CONFIG_SITE?
+# build_config_opts="${build_config_opts} --cache-file=/dev/null"
+# export CONFIG_SITE=$(pwd)/config.site
+# cat < < E OF > config.site
+
+build_config_opts="${build_config_opts} --config-cache"
Re: mknetrel for president
Christopher Faylor <[EMAIL PROTECTED]> writes: > On Mon, Jul 08, 2002 at 10:39:12AM -0400, Charles Wilson wrote: >>I'll reiterate Chris' comment, here: one tool, one job. Perhaps the >>"let's make a cross build env" part could be a *separate* script, that >>USES mknetrel. > > Actually, the mknetrel CVS repository has a couple of small tools: > "bump" and "pimport". bump changes the version number of a source > directory. pimport takes a tar file and puts it in the src directory, > correctly named. > > pimport might be a good place to put a "grab stuff from the ftp site" > logic. Ok. I didn't look close enough at the resulting packages. As it turns out, there's another difference with the cygwin-cross tools: mknetrel uses packaging method1, where the cross-tools use method2. Actually, I had the impression that method1 was more or less deprecated, and that we were moving to method2? For packaging method2, it makes a lot of sense for `the packaging tool' to untar the (pristine) source itself, to assure the diff that gets generated is correct. Anyway, we'll see about that later. First, the mknetrel patches. Greetings, Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: [PATCH]: mknetrel builds Guile #1: init
Christopher Faylor <[EMAIL PROTECTED]> writes: > I've checked in a modified version of this patch. Thanks! > I eliminated some of the wording in the README. Especially the parts > that say that mknetrel is a cross build tool. Can we lay that one to > rest now? Sure. But it's *also* a cross build tool; it is (was) even configured that way. It may be good if google would find mknetrel when you look for cygwin+cross+packaging? > The ChangeLog was not GNU standard, either. It wasn't? Sorry, I'll have a close look at CVS. > I think you can safely assume that I want the same kind of > ChangeLogs (not ChangeLog patches) as are mentioned on > http://cygwin.com/contrib.html . Hmm, very odd. I'll try to remember this exception. > Oh, one part wasn't. The layout is supposed to be like this: > > /netrel > bin > extra > src > inst > uploads > log > > So, the location of extra was not erroneous. I don't think so; it depends on your defaults. This is only the so in the 'exceptional' case where netrel_root=. My layout is: ~/cvs/cygwin/cygwin-apps/mknetrel/bin /extra /home/cygwin/netrel/src inst uploads /bin and /extra are in the mknetrel source dir, and the others may well be somewhere else. Without this fix, mknetrel tries to find /extra under /netrel. Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: [PATCH]: mknetrel builds Guile #2: debug
Christopher Faylor <[EMAIL PROTECTED]> writes:
>> - add debugging feature: drop to shell upon failure
>
> I normally run mknetrel in the background. In fact, I just added a
> couple of options to accommodate this. They would conflict with this
> patch.
Ok.
> If you want to add this functionality, introduce an option. I don't
> want to have this as the default.
Sure, that's inconvenient. I thought about adding it to -x, but you
may well want to have a detailed, noninteractive log, at times. So,
I decided to add -X option for this.
Also, I made -h exit successfully, not to annoy you or anything, saw
you were messing with this too. Hope you like the way I did it. I
thought about adding a help () funtion, but decided that would be
overkill.
What I really think we should also do, is to start the script with
set -e
and let bash decide when something's wrong. Then we can rid of stuff
like:
mkdir foo || exit 1
It is annoying that you'll have to add '|| true' clauses to some
checks that are allowed to fail, but in general, I feel that a bourn
script *should* start with set -e. Any sane interpreter stops upon
error. What do you think?
Greetings,
Jan.
Btw: A very silly question, but I can't seem to get `cvs diff' to
respect your (Cygwin's?) wishes of excluding the ChangeLog from
the diff. It doesn't grok -X,--exclude options, most annoying.
How do you manage?
2002-07-09 Jan Nieuwenhuizen <[EMAIL PROTECTED]>
* bin/mknetrel: Invoke atexit () before exiting.
(atexit): New function.
(drop): New funtion.
(usage): Return (previously: exit unsuccessfully).
(setup): Add -X option to make mknetrel drop to shell upon error.
Exit successfully for -h, unsuccessfully upon usage error.
(setup1): Exit unsuccessfully upon usage error.
* .cvsignore: Add .bash_mknetrel.
? pats
Index: .cvsignore
===
RCS file: /cvs/cygwin-apps/mknetrel/.cvsignore,v
retrieving revision 1.2
diff -p -u -r1.2 .cvsignore
--- .cvsignore 9 Jul 2002 03:32:14 - 1.2
+++ .cvsignore 9 Jul 2002 12:06:38 -
@@ -4,6 +4,7 @@ Makefile
#*
*.swp
.cvsignore
+.bash_mknetrel
build
inst
log
Index: ChangeLog
===
RCS file: /cvs/cygwin-apps/mknetrel/ChangeLog,v
retrieving revision 1.14
diff -p -u -r1.14 ChangeLog
--- ChangeLog 9 Jul 2002 06:01:59 -0000 1.14
+++ ChangeLog 9 Jul 2002 12:06:38 -
@@ -1,3 +1,15 @@
+2002-07-09 Jan Nieuwenhuizen <[EMAIL PROTECTED]>
+
+ * bin/mknetrel: Invoke atexit () before exiting.
+ (atexit): New function.
+ (drop): New funtion.
+ (usage): Return (previously: exit unsuccessfully).
+ (setup): Add -X option to make mknetrel drop to shell upon error.
+ Exit successfully for -h, unsuccessfully upon usage error.
+ (setup1): Exit unsuccessfully upon usage error.
+
+ * .cvsignore: Add .bash_mknetrel.
+
2002-07-09 Christopher Faylor <[EMAIL PROTECTED]>
* bin/mknetrel (doconfig): Fix more quoting problems.
Index: bin/mknetrel
===
RCS file: /cvs/cygwin-apps/mknetrel/bin/mknetrel,v
retrieving revision 1.33
diff -p -u -r1.33 mknetrel
--- bin/mknetrel9 Jul 2002 06:32:17 - 1.33
+++ bin/mknetrel9 Jul 2002 12:06:38 -
@@ -32,6 +32,24 @@ read_user_config() {
export knownpath
}
+atexit () { :; }
+
+trap atexit 0 9 15
+
+# Interactive shell with state of bash at exit upon failure
+drop ()
+{
+[ "$?" -eq 0 ] && trap - 0 9 15 && exit 0 || true
+echo "$0: dropping to shell..."
+set | sed -e 's/^\(BASH_VERSINFO=\)/#\1/' \
+ -e 's/^\(EUID=\)/#\1/' \
+ -e 's/^\(PPID=\)/#\1/' \
+ -e 's/^\(SHELLOPTS=\)/#\1/' \
+ -e 's/^\(UID=\)/#\1/' > .bash_mknetrel
+echo "PS1='mknetrel-debug \w$ '" >> .bash_mknetrel
+exec bash --rcfile .bash_mknetrel
+}
+
setvars() {
cd $netrel_root || exit 1
here=`pwd`
@@ -86,19 +104,20 @@ setup() {
read_user_config
clean=false
opt="-O2"
-while getopts 'ihtbcCgNnxSoB' o; do
+while getopts 'ihtbcCgNnxXSoB' o; do
case "$o" in
'b') rebuild() { dorebuild; } ;;
'B') background() { return 0;}; output() { return 0;} ;;
'c') config() { doconfig; }; rebuild() { dorebuild; } ;;
'C') clean=: ;;
'g') opt="-O2 -g"; rebuild() { dorebuild; } ;;
- 'h') usage ;;
+ 'h') usage; exit 0;;
'i') knownpath= ;
Re: [PATCH]: mknetrel builds Guile #2: debug
Jan Nieuwenhuizen <[EMAIL PROTECTED]> writes:
Aarg, copied the original patch, including ChangeLog. Sorry
2002-07-09 Jan Nieuwenhuizen <[EMAIL PROTECTED]>
* bin/mknetrel: Invoke atexit () before exiting.
(atexit): New function.
(drop): New funtion.
(usage): Return (previously: exit unsuccessfully).
(setup): Add -X option to make mknetrel drop to shell upon error.
Exit successfully for -h, unsuccessfully upon usage error.
(setup1): Exit unsuccessfully upon usage error.
* .cvsignore: Add .bash_mknetrel.
? pats
Index: .cvsignore
===
RCS file: /cvs/cygwin-apps/mknetrel/.cvsignore,v
retrieving revision 1.2
diff -p -u -r1.2 .cvsignore
--- .cvsignore 9 Jul 2002 03:32:14 - 1.2
+++ .cvsignore 9 Jul 2002 12:06:38 -
@@ -4,6 +4,7 @@ Makefile
#*
*.swp
.cvsignore
+.bash_mknetrel
build
inst
log
Index: bin/mknetrel
===
RCS file: /cvs/cygwin-apps/mknetrel/bin/mknetrel,v
retrieving revision 1.33
diff -p -u -r1.33 mknetrel
--- bin/mknetrel9 Jul 2002 06:32:17 - 1.33
+++ bin/mknetrel9 Jul 2002 12:06:38 -
@@ -32,6 +32,24 @@ read_user_config() {
export knownpath
}
+atexit () { :; }
+
+trap atexit 0 9 15
+
+# Interactive shell with state of bash at exit upon failure
+drop ()
+{
+[ "$?" -eq 0 ] && trap - 0 9 15 && exit 0 || true
+echo "$0: dropping to shell..."
+set | sed -e 's/^\(BASH_VERSINFO=\)/#\1/' \
+ -e 's/^\(EUID=\)/#\1/' \
+ -e 's/^\(PPID=\)/#\1/' \
+ -e 's/^\(SHELLOPTS=\)/#\1/' \
+ -e 's/^\(UID=\)/#\1/' > .bash_mknetrel
+echo "PS1='mknetrel-debug \w$ '" >> .bash_mknetrel
+exec bash --rcfile .bash_mknetrel
+}
+
setvars() {
cd $netrel_root || exit 1
here=`pwd`
@@ -86,19 +104,20 @@ setup() {
read_user_config
clean=false
opt="-O2"
-while getopts 'ihtbcCgNnxSoB' o; do
+while getopts 'ihtbcCgNnxXSoB' o; do
case "$o" in
'b') rebuild() { dorebuild; } ;;
'B') background() { return 0;}; output() { return 0;} ;;
'c') config() { doconfig; }; rebuild() { dorebuild; } ;;
'C') clean=: ;;
'g') opt="-O2 -g"; rebuild() { dorebuild; } ;;
- 'h') usage ;;
+ 'h') usage; exit 0;;
'i') knownpath= ;;
'n') mkdist() { :; } ;;
'o') output() { return 0; } ;;
'S') stripbins() { return 1; } ;;
'x') verbose() { set -x; } ;;
+ 'X') atexit() { drop; } ;;
'?') exit 1 ;;
esac
done
@@ -107,6 +126,7 @@ setup() {
what=$1
if [ -z "$what" ]; then
usage "missing package name"
+ exit 1
fi
setvars $what
@@ -122,6 +142,7 @@ setup1() {
export PATH
if [ -z "$what" ]; then
usage "missing package name"
+ exit 1
fi
[ -d "$build" ] || clean=:
@@ -324,8 +345,8 @@ usage() {
-o Redirect output to $mknetrel_root/log/*.out
-S Don't strip binaries
-t Tag sourceware with release info
- -x Verbose shell output"
-exit 1
+ -x Verbose shell output
+ -X Drop to a shell upon error"
}
rest() {
--
Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: [PATCH]: mknetrel builds Guile #2: debug
Earnie Boyd <[EMAIL PROTECTED]> writes: >> Btw: A very silly question, but I can't seem to get `cvs diff' to >> respect your (Cygwin's?) wishes of excluding the ChangeLog from >> the diff. It doesn't grok -X,--exclude options, most annoying. >> How do you manage? >> > > Remove the ChangeLog diff from the patch. Copy the text from the > ChangeLog to the top of the diff file. Patch is smart enough to ignore > the non-diff text in the front of the file. Hrmm. If you're going to have nonstandard requests, it would be handy if these somehow would be handled automagically. How dead is CVS development, maybe they would take a patch? Greetings, Jan -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: [PATCH]: mknetrel builds Guile #2: debug
Earnie Boyd <[EMAIL PROTECTED]> writes: >> >> Btw: A very silly question, but I can't seem to get `cvs diff' to >> >> respect your (Cygwin's?) wishes of excluding the ChangeLog from >> >> the diff. It doesn't grok -X,--exclude options, most annoying. >> >> How do you manage? >> >> >> > >> > Remove the ChangeLog diff from the patch. Copy the text from the >> > ChangeLog to the top of the diff file. Patch is smart enough to ignore >> > the non-diff text in the front of the file. >> >> Hrmm. If you're going to have nonstandard requests, it would be handy >> if these somehow would be handled automagically. How dead is CVS >> development, maybe they would take a patch? >> > > This has nothing to do with CVS. Well, it would help if cvs allowed: cvs diff -X ChangeLog and even more, if project that want this had: /.cvsrc: diff -XChangeLog > It has to do with standards set by the development teams and the > fact that your changes to ChangeLog often (most likely) cause merge > conflicts. Yes, I understand. Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: [PATCH]: mknetrel builds Guile #2: debug
Charles Wilson <[EMAIL PROTECTED]> writes: > That's why I am investigating transitioning us to a cygwin port of > cvsnt (no, it's not just for native windows anymore...) And it does work with emacs' pcvs.el, right? > The thing about the ChangeLog stuff, is that it really isn't that > non-standard. MOST projects dislike *patches* to ChangeLog files, Maybe just my ignorance that I haven't seen these requests before. It's not so much that I dislike project specific stuff (look at LilyPond), but the fact that the current tools don't handle it gracefully, let alone automagically. > This is because a patch to ChangeLog *never* (okay, ALMOST never) > applies cleanly, Ack. > I tend NOT to modify the ChangeLog at all -- I put my ChangeLog > entries in a separate file, and paste that into the email by hand... Ok, I'm going to try that. Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: [PATCH]: mknetrel builds Guile #5: split
Christopher Faylor <[EMAIL PROTECTED]> writes: > On Tue, Jul 09, 2002 at 02:14:54AM +0200, Jan Nieuwenhuizen wrote: >> >> - add funtionality to split into and build sub packages > > I suspect that this functionality could also be handled with judicious > use of extra/whatever files. Sure. All of the configuring, building and packaging can be handled by other scripts than mknetrel-core. I was just hoping that we could reduce duplication of effort. A good half-way alternative that I would like to suggest, is to prepare domkdist () for subpackaging, just like I did; but move the *_name and *_split funtions out to extra/whatever. Note that Chuck posted a comment about how debian's packaging rules (a good part of this is splitting packages) is all duplicated; which would be a thing to avoid. That's also why I suggested something like this patch. What do you think? > Also, why should build_prefix ever be anything but /usr? Lots of reasons. It doesn't really hurt, too? Or am I being too flexible. This is a minor point, imo. Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: [PATCH]: mknetrel builds Guile #4: genscript
Christopher Faylor <[EMAIL PROTECTED]> writes: > On Tue, Jul 09, 2002 at 02:14:37AM +0200, Jan Nieuwenhuizen wrote: >> >> - autogenerate cygwin build script: $package.sh > > This looks like a prepackage function to me. No need to modify mknetrel. I think that you do not understand. This will autogenerate, package (and thus offer the end user) a script named $package.sh, that will rebuild the package from source. I think users would find this quite valuable, although you might have another opinion on the implementation. If you hadn't scared me into sending small patches, I would move all functions out of mknetrel, and import that file in mknetrel and the $package.sh script. The script is a requirement for Method2, and I'd like to slowly move towards that packaging method. Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Guile-1.5.6-3 available for upload
Hi, There just one small bugreport on -2, from Chuck, which has been fixed, so I think this is it. There was some delay because I had hoped, after spending the weekend and yesterday night hacking on mknetrel, to junk my cygwin-cross tools and use mknetrel for packaging Guile, but alas, it appears that it's not going to be that way any time soon. Please upload [if you don't spot some stupid mistake]. guile (1.5.6-3) unstable; urgency=low * Bugfix for native buildscript. * Development package named guile-devel (previously libguile-devel). -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> Tue, 9 Jul 2002 03:22:54 +0200 Greetings, Jan. And here the repeatable data: Guile version 1.5.6-3, is now available for uploading at: http://lilypond.org/cygwin/tar/guile After a successful installation of guile (and libguile14), you should be able to run, eg, guile -c '(begin (write (string-append "hello: " (version) "\n")))' [there may be a working setup.ini at http://lilypond.org/cygwin] http://lilypond.org/cygwin/tar/guile/setup.hint sdesc: "The GNU extension language and Scheme interpreter (executable)" category: interpreters requires: cygwin libguile14 ldesc: "The GNU extension language and Scheme interpreter (executable) Guile, the GNU Ubiquitous Intelligent Language for Extension, is a scheme implementation designed for real world programming, supporting a rich Unix interface, a module system, and undergoing rapid development. `guile' is a scheme interpreter that can execute scheme scripts (with a #! line at the top of the file), or run as an inferior scheme process inside Emacs." http://lilypond.org/cygwin/tar/guile/guile-1.5.6-3.README http://lilypond.org/cygwin/tar/guile/guile-1.5.6-3-src.tar.bz2 http://lilypond.org/cygwin/tar/guile/guile-1.5.6-3.tar.bz2 === http://lilypond.org/cygwin/tar/guile/guile-doc/setup.hint sdesc: "The GNU extension language and Scheme interpreter (documentation)" category: doc requires: cygwin external-source: guile ldesc: "The GNU extension language and Scheme interpreter (documentation) This package contains the documentation for guile, including both a reference manual (via `info guile'), and a tutorial (via `info guile-tut')." http://lilypond.org/cygwin/tar/guile/guile-doc/guile-doc-1.5.6-3.tar.bz2 === http://lilypond.org/cygwin/tar/guile/libguile14/setup.hint sdesc: "The GNU extension language and Scheme interpreter (runtime libraries)" category: libs requires: cygwin external-source: guile ldesc: "The GNU extension language and Scheme interpreter (runtime libraries) Guile shared object libraries and the ice-9 scheme module. Guile is the GNU Ubiquitous Intelligent Language for Extension." http://lilypond.org/cygwin/tar/guile/libguile14/libguile14-1.5.6-3.tar.bz2 === http://lilypond.org/cygwin/tar/guile/guile-devel/setup.hint sdesc: "Development headers and static libraries for Guile." category: devel libs requires: cygwin external-source: guile ldesc: "Development headers and static libraries for Guile. `libguile.h' etc. C headers, aclocal macros, the `guile-snarf' and `guile-config' utilities, and static `libguile.a' libraries for Guile, the GNU Ubiquitous Intelligent Language for Extension." http://lilypond.org/cygwin/tar/guile/guile-devel/guile-devel-1.5.6-3.tar.bz2 -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: [PATCH]: mknetrel builds Guile #3: libtool
Christopher Faylor <[EMAIL PROTECTED]> writes: > On Tue, Jul 09, 2002 at 02:14:16AM +0200, Jan Nieuwenhuizen wrote: >> >> - fixes and preparations for building with libtool >> > > Sorry, but I don't like this one. Does libtool *really* need to run > ld directly? That seems ill advised to me. It's usually better to > just run gcc. Ok. So libtool is probably still broken. I'm not going to fix libtool and cannot allow myself to spend too much extra time on this. (Actually, I've spent so much time on Guile and Cygwin the past week, that I had complaints from a Lily developer; we're gearing up for 1.6). In the meantime, I must see Guile being packaged. I've offered you a, as I think, fairly clean and concise workaround to build libtool DLLs with mknetrel, with Guile as a nice working example for others to follow. As it stands, I don't see a good way now to use mknetrel to build Guile, so I probably won't bother you with patches to build Guile (or libtool packages) with mknetrel. Jan -- who's a bit sad to be forced back to his cygwin-cross tools. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: [PATCH]: mknetrel builds Guile #4: genscript
Charles Wilson <[EMAIL PROTECTED]> writes: > If we want to add a "method 3" which is: > > donwload current mknetrel > copy the included script 'pkgname' into mknetrel/extra (*) > run mknetrel -b > > (*) where 'pkgname' is the override script. > > That would be fine, too, IMO. Ah, now that would be smart thing to do, why didn't I think of that? What about picking a directory for extra right now, let's say: /usr/share/mknetrel/extra and have individual packages all unpack their extra script there (maybe even junk most extra's from mknetrel-cvs itself)? Any volunteers for packaging mknetrel? Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: [PATCH]: mknetrel builds Guile #3: libtool
Charles Wilson <[EMAIL PROTECTED]> writes: > I think you made the right decision to go ahead with guile for now. > You can always release the next version/update of guile using mknetrel > if/when it will do what you need. Ok. It was just that I really wanted to strive to unite efforts, esp. after your compassionate post about packaging... > But don't give up on mknetrel -- it is GOOD that cgf is going slow > and careful. Yes, of course it is. At times I wish for our dictators to be a bit more benevolent, esp. after several long night hacking sessions. It's easy to get a bit frustated upon a reject. > Slow and steady wins the race. You don't have reach the "ultimate > solution" with mknetrel right away. Come back to it after lily-1.66, > and see how you can work with cgf's requirements. Sure I will. I'm just always a bit impatient. I already resubmitted patch #2 (debug), and made some suggestions for changes in #5 (split). Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
