What does Yhc need (error, ffi.h not found)
Trying scons on a freshly darcs'd yhc from today, I got an error, see: http://paste.lisp.org/display/22129 or, to include the relevant parts of the output here: gcc -I. -c -o src/runtime/BCKernel/external.o src/runtime/BCKernel/external.c In file included from src/runtime/BCKernel/types.h:5, from src/runtime/BCKernel/hashtable.h:4, from src/runtime/BCKernel/module.h:18, from src/runtime/BCKernel/external.h:4, from src/runtime/BCKernel/external.c:1: src/runtime/BCKernel/platform.h:103:17: ffi.h: No such file or directory scons: *** [src/runtime/BCKernel/external.o] Error 1 scons: building terminated because of errors. On IRC, ndm suggested that "libffi" was needed; after "emerge libffi" the error still happened -- so, me being on gentoo-linux ppc, ndm on Windows, referred me to this list. I'm trying to find out what is actually needed to successfully compile Yhc (now, for me, at least).
Hi Isaac,
can you build any program using ffi.h? e.g.
--- test.c ------------
#include
Trying scons on a freshly darcs'd yhc from today, I got an error, see: http://paste.lisp.org/display/22129 or, to include the relevant parts of the output here:
gcc -I. -c -o src/runtime/BCKernel/external.o src/runtime/BCKernel/external.c In file included from src/runtime/BCKernel/types.h:5, from src/runtime/BCKernel/hashtable.h:4, from src/runtime/BCKernel/module.h:18, from src/runtime/BCKernel/external.h:4, from src/runtime/BCKernel/external.c:1: src/runtime/BCKernel/platform.h:103:17: ffi.h: No such file or directory scons: *** [src/runtime/BCKernel/external.o] Error 1 scons: building terminated because of errors.
On IRC, ndm suggested that "libffi" was needed; after "emerge libffi" the error still happened -- so, me being on gentoo-linux ppc, ndm on Windows, referred me to this list. I'm trying to find out what is actually needed to successfully compile Yhc (now, for me, at least). _______________________________________________ Yhc mailing list Yhc@haskell.org http://www.haskell.org//mailman/listinfo/yhc
Yes, I can compile that program "test.c" with gcc -c test.c Just to test, without darcs-pulling anything, I re-ran scons on yhc, and it worked to a greater extent than before (then erroring with: /usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.4/../../../../powerpc-unknown-linux-gnu/bin/ld: cannot find -lffi ) There must have been something temporary affecting that (my computer was rebooted in between). After darcs pull, scons errored: scons: warning: Ignoring missing SConscript 'src/packages/yhc-base-1.0/YHC/Runtime/SConscript' File "src/packages/yhc-base-1.0/YHC/SConscript", line 9, in ? TypeError: iteration over non-sequence: File "Sconstruct", line 47: yhi_objs, yhcfiles, library, testerfiles = SConscript("src/SConscript") File "/usr/lib/scons/SCons/Script/SConscript.py", line 581: return apply(method, args, kw) File "/usr/lib/scons/SCons/Script/SConscript.py", line 508: return apply(_SConscript, [self.fs,] + files, {'exports' : exports}) File "/usr/lib/scons/SCons/Script/SConscript.py", line 239: exec _file_ in stack[-1].globals File "src/SConscript", line 7: yhc_lib = SConscript("packages/SConscript") File "/usr/lib/scons/SCons/Script/SConscript.py", line 581: return apply(method, args, kw) File "/usr/lib/scons/SCons/Script/SConscript.py", line 508: return apply(_SConscript, [self.fs,] + files, {'exports' : exports}) File "/usr/lib/scons/SCons/Script/SConscript.py", line 239: exec _file_ in stack[-1].globals File "src/packages/SConscript", line 3: yhcobjs = SConscript("yhc-base-1.0/SConscript") File "/usr/lib/scons/SCons/Script/SConscript.py", line 581: return apply(method, args, kw) File "/usr/lib/scons/SCons/Script/SConscript.py", line 508: return apply(_SConscript, [self.fs,] + files, {'exports' : exports}) File "/usr/lib/scons/SCons/Script/SConscript.py", line 239: exec _file_ in stack[-1].globals File "src/packages/yhc-base-1.0/SConscript", line 55: objs += SConscript("YHC/SConscript") File "/usr/lib/scons/SCons/Script/SConscript.py", line 581: return apply(method, args, kw) File "/usr/lib/scons/SCons/Script/SConscript.py", line 508: return apply(_SConscript, [self.fs,] + files, {'exports' : exports}) File "/usr/lib/scons/SCons/Script/SConscript.py", line 239: exec _file_ in stack[-1].globals File "src/packages/yhc-base-1.0/YHC/SConscript", line 9: objs += SConscript("Runtime/SConscript") darcs unpull'ing only those new patches that didn't look like they had to do with ffi, scons then reached the same "cannot find -lffi" error. Thomas Shackell wrote:
Hi Isaac,
can you build any program using ffi.h? e.g.
--- test.c ------------
#include
int main(){ return 0; }
-----------------------
gcc -c test.c
cheers
Tom
Isaac wrote:
Trying scons on a freshly darcs'd yhc from today, I got an error, see: http://paste.lisp.org/display/22129 or, to include the relevant parts of the output here:
gcc -I. -c -o src/runtime/BCKernel/external.o src/runtime/BCKernel/external.c In file included from src/runtime/BCKernel/types.h:5, from src/runtime/BCKernel/hashtable.h:4, from src/runtime/BCKernel/module.h:18, from src/runtime/BCKernel/external.h:4, from src/runtime/BCKernel/external.c:1: src/runtime/BCKernel/platform.h:103:17: ffi.h: No such file or directory scons: *** [src/runtime/BCKernel/external.o] Error 1 scons: building terminated because of errors.
On IRC, ndm suggested that "libffi" was needed; after "emerge libffi" the error still happened -- so, me being on gentoo-linux ppc, ndm on Windows, referred me to this list. I'm trying to find out what is actually needed to successfully compile Yhc (now, for me, at least). _______________________________________________ Yhc mailing list Yhc@haskell.org http://www.haskell.org//mailman/listinfo/yhc
Isaac wrote:
Yes, I can compile that program "test.c" with gcc -c test.c Just to test, without darcs-pulling anything, I re-ran scons on yhc, and it worked to a greater extent than before (then erroring with: /usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.4/../../../../powerpc-unknown-linux-gnu/bin/ld: cannot find -lffi ) There must have been something temporary affecting that (my computer was rebooted in between).
does gcc test.c -lffi work? :-)
After darcs pull, scons errored:
<snip scons error> sorry my fault, forgot to add a file to the repo when I made a change. thanks :-) Tom
:) no, adding -lffi to the test doesn't work: /usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.4/../../../../powerpc-unknown-linux-gnu/bin/ld: cannot find -lffi collect2: ld returned 1 exit status And now that the scons has been fixed up, it gives me, as expected, Checking for ffi_call() in C library ffi... no YHC requires LibFFI to be installed and working. In case the information helps: the version of libffi (it seemed like) I installed was 3.4.3, corresponding to the GCC release of that version number (indeed, using its source code). (Although it's very probably irrelevant, I'm using GCC 3.4.4 as my C compiler.) Now looking around, I found /usr/lib/libffi -- it's a directory! $ ls -lR /usr/lib/libffi/ /usr/lib/libffi/: total 48 -rw-r--r-- 1 root root 19970 Jul 5 17:31 libffi.a -rwxr-xr-x 1 root root 722 Jul 5 17:31 libffi.la lrwxrwxrwx 1 root root 15 Jul 5 17:31 libffi.so -> libffi.so.3.0.0 lrwxrwxrwx 1 root root 15 Jul 5 17:31 libffi.so.3 ->libffi.so.3.0.0 -rwxr-xr-x 1 root root 18640 Jul 5 17:31 libffi.so.3.0.0 drwxr-xr-x 2 root root 4096 Jul 5 17:31 nof /usr/lib/libffi/nof: total 52 -rw-r--r-- 1 root root 21386 Jul 5 17:31 libffi.a -rwxr-xr-x 1 root root 726 Jul 5 17:31 libffi.la lrwxrwxrwx 1 root root 15 Jul 5 17:31 libffi.so -> libffi.so.3.0.0 lrwxrwxrwx 1 root root 15 Jul 5 17:31 libffi.so.3 ->libffi.so.3.0.0 -rwxr-xr-x 1 root root 21104 Jul 5 17:31 libffi.so.3.0.0 [a couple spaces deleted to keep the lines from wrapping] I don't know how much of this setup is Gentoo-specific, though, and I don't know how libffi would generically be installed (e.g. starting from the source tarball) in general. Thomas Shackell wrote:
Isaac wrote:
Yes, I can compile that program "test.c" with gcc -c test.c Just to test, without darcs-pulling anything, I re-ran scons on yhc, and it worked to a greater extent than before (then erroring with: /usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.4/../../../../powerpc-unknown-linux-gnu/bin/ld:
cannot find -lffi ) There must have been something temporary affecting that (my computer was rebooted in between).
does gcc test.c -lffi work? :-)
After darcs pull, scons errored:
<snip scons error>
sorry my fault, forgot to add a file to the repo when I made a change.
thanks :-)
Tom
This is gentoo specific I believe, installing libffi in Ubuntu with apt-get libffi4-dev gives me (tom@mitsumi:~)$ ls /usr/lib/libffi* /usr/lib/libffi.a /usr/lib/libffi.so /usr/lib/libffi.so.4.0.1 /usr/lib/libffi.la /usr/lib/libffi.so.4 so I guess you need to add it to your LIBRARY_PATH and possibly LD_LIBRARY_PATH :-) Tom Isaac wrote:
:) no, adding -lffi to the test doesn't work:
/usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.4/../../../../powerpc-unknown-linux-gnu/bin/ld: cannot find -lffi collect2: ld returned 1 exit status
And now that the scons has been fixed up, it gives me, as expected,
Checking for ffi_call() in C library ffi... no YHC requires LibFFI to be installed and working.
In case the information helps: the version of libffi (it seemed like) I installed was 3.4.3, corresponding to the GCC release of that version number (indeed, using its source code). (Although it's very probably irrelevant, I'm using GCC 3.4.4 as my C compiler.)
Now looking around, I found /usr/lib/libffi -- it's a directory! $ ls -lR /usr/lib/libffi/ /usr/lib/libffi/: total 48 -rw-r--r-- 1 root root 19970 Jul 5 17:31 libffi.a -rwxr-xr-x 1 root root 722 Jul 5 17:31 libffi.la lrwxrwxrwx 1 root root 15 Jul 5 17:31 libffi.so -> libffi.so.3.0.0 lrwxrwxrwx 1 root root 15 Jul 5 17:31 libffi.so.3 ->libffi.so.3.0.0 -rwxr-xr-x 1 root root 18640 Jul 5 17:31 libffi.so.3.0.0 drwxr-xr-x 2 root root 4096 Jul 5 17:31 nof
/usr/lib/libffi/nof: total 52 -rw-r--r-- 1 root root 21386 Jul 5 17:31 libffi.a -rwxr-xr-x 1 root root 726 Jul 5 17:31 libffi.la lrwxrwxrwx 1 root root 15 Jul 5 17:31 libffi.so -> libffi.so.3.0.0 lrwxrwxrwx 1 root root 15 Jul 5 17:31 libffi.so.3 ->libffi.so.3.0.0 -rwxr-xr-x 1 root root 21104 Jul 5 17:31 libffi.so.3.0.0
[a couple spaces deleted to keep the lines from wrapping]
I don't know how much of this setup is Gentoo-specific, though, and I don't know how libffi would generically be installed (e.g. starting from the source tarball) in general.
Thomas Shackell wrote:
Isaac wrote:
Yes, I can compile that program "test.c" with gcc -c test.c Just to test, without darcs-pulling anything, I re-ran scons on yhc, and it worked to a greater extent than before (then erroring with: /usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.4/../../../../powerpc-unknown-linux-gnu/bin/ld:
cannot find -lffi ) There must have been something temporary affecting that (my computer was rebooted in between). does gcc test.c -lffi work? :-)
After darcs pull, scons errored: <snip scons error>
sorry my fault, forgot to add a file to the repo when I made a change.
thanks :-)
Tom
I've done some more investigating on this and it's not as easy to solve as it first seems. Gentoo stores libffi.so in /usr/lib/libffi and ffi.h in /usr/include/libffi which is fine, a small change to the build script lets it pick up the right files. The problem is that the libffi provided by Gentoo is out of date with respect to the current stable compiler so the built yhi seg faults.
From what I can gather from the Gentoo bugzilla some people want libffi removed from portage entirely. Libffi *might* be built if you enable to the gcj use flag when compiling gcc, it's a little unclear on that. I will try rebuilding my version of gcc with that flag over the weekend.
As the build system builds it's own libffi on Windows it shouldn't be too hard to do the same on other platforms, and I think that is the way forward. Where is the best place to get libffi from? I don't really want to have to download the whole of the gcc sourcecode... Andrew
Hi
As the build system builds it's own libffi on Windows it shouldn't be too hard to do the same on other platforms, and I think that is the way forward. Where is the best place to get libffi from? I don't really want to have to download the whole of the gcc sourcecode...
Why not just ctypes? I know its not AMD64 yet, but it seems a shame to use different copies of libffi from different sources for different platforms... Neil
Neil Mitchell wrote:
Why not just ctypes?
I know its not AMD64 yet, but it seems a shame to use different copies of libffi from different sources for different platforms...
Assuming this is the "ctypes" google is telling me about ( http://starship.python.net/crew/theller/ctypes/ ), that page indicates that it does work on AMD64 ... :?
Assuming this is the "ctypes" google is telling me about ( http://starship.python.net/crew/theller/ctypes/ ), that page indicates that it does work on AMD64 ... :?
I also saw: http://mail.python.org/pipermail/python-dev/2006-March/062211.html "ctypes is now in SVN" And searching further I can find: http://svn.python.org/view/ctypes/trunk/ctypes/source/libffi/src/x86/unix64.S?rev=50076&view=markup In the python ctypes svn there is indeed amd64 See http://svn.python.org/view/ctypes/trunk/ctypes/source/ for the ctypes SVN stuff. I guess we should move to this, and have all our ffi issues solved for free? Thanks Neil
Sounds interesting. Thanks for the links guys, I will write some patches for the build process to use this version of ctypes on Monday and I'll report back :-) Andrew
Hi all, I've updated Yhc to not rely on an external libffi and everything is done 'in-house'. Instead of requiring cvs on Windows it now requires Subversion on all platforms. It works for me, and even builds on Gentoo - although half of the tests fail and I'm not sure why yet. Please try it out and let me know any error messages that you get! Andrew
Andrew Wilkinson wrote:
Please try it out and let me know any error messages that you get!
$ scons scons: Reading SConscript files ... svn co http://svn.python.org/projects/ctypes/trunk/ctypes/source/ depends/ctypes sh: svn: command not found Bootstrapping... IOError: [Errno 2] No such file or directory: 'depends/ctypes/SConscript': File "Sconstruct", line 32: bootstrap(env) File "/home/isaac/build/yhc-devel/build/bootstrap.py", line 13: copy(env, "depends/ctypes/SConscript", "build/SConscript.ctypes") File "/home/isaac/build/yhc-devel/build/bootstrap.py", line 32: open(to, "w").write(open(file, "r").read()) # is there a better way to copy a file? In other words, I didn't have subversion installed. It would be nice if the resulting error messages were a bit more obvious though. After installing subversion and darcs-pulling again, here is the end of its log (it failed) (I've added a few ###[annotations]### manually): [...] Checked out revision 50525. ###[of ctypes]### Bootstrapping... Done. Checking whether byte ordering is bigendian... failed ###[bad]### Checking size of char... 1 Checking size of short... 2 Checking size of int... 4 Checking size of long... 4 Checking size of long long... 8 Checking size of float... 4 Checking size of double... 8 Checking size of void*... 4 Checking for pthread_create() in C library pthread... yes Generating config.h with the following settings: WORDS_BIGENDIAN None ###[bad]### HAVE_LIBPTHREAD 1 SIZEOF_LONG_LONG 8 SIZEOF_LONG 4 WIN32 0 SIZEOF_VOIDP 4 SIZEOF_CHAR 1 SIZEOF_DOUBLE 8 SIZEOF_FLOAT 4 SIZEOF_INT 4 HAVE_GCC_LABELS 1 SIZEOF_SHORT 2 TypeError: int argument required: File "Sconstruct", line 35: configure(env, Configure) # Configure File "/home/isaac/build/yhc-devel/build/configure.py", line 42: config_h_build('config.h', 'config.h.new.in', vals) File "/home/isaac/build/yhc-devel/build/config_h.py", line 21: text = config_h_in.read() % defines (I'm on powerpc which is big-endian) Isaac
Hi,
Thanks for the bug reports, I don't have a big endian machine to test Yhc on
so it's quite hard to debug the builds. I'm trying to get my department to
install scons onto a Solaris SPARC machine so I can test on that.
I have added tests for Subversion and GHC so you'll get proper error
messages if the correct programs are not installed.
Can you try going into the .scons_temp subdirectory under whereever you
built yhc? In there will be a collection of source code files, executables
and text files holding the output. One of them will be the program which
determines whether the machine is big endian. If you could run that directly
from a consol and tell me what the output is that would be helpful. I have
run that program standalone under Solaris and got the correct output.
Cheers,
Andrew
On 7/10/06, Isaac
Andrew Wilkinson wrote:
Please try it out and let me know any error messages that you get!
$ scons scons: Reading SConscript files ... svn co http://svn.python.org/projects/ctypes/trunk/ctypes/source/ depends/ctypes sh: svn: command not found Bootstrapping... IOError: [Errno 2] No such file or directory: 'depends/ctypes/SConscript': File "Sconstruct", line 32: bootstrap(env) File "/home/isaac/build/yhc-devel/build/bootstrap.py", line 13: copy(env, "depends/ctypes/SConscript", "build/SConscript.ctypes") File "/home/isaac/build/yhc-devel/build/bootstrap.py", line 32: open(to, "w").write(open(file, "r").read()) # is there a better way to copy a file?
In other words, I didn't have subversion installed. It would be nice if the resulting error messages were a bit more obvious though.
After installing subversion and darcs-pulling again, here is the end of its log (it failed) (I've added a few ###[annotations]### manually): [...] Checked out revision 50525. ###[of ctypes]### Bootstrapping... Done. Checking whether byte ordering is bigendian... failed ###[bad]### Checking size of char... 1 Checking size of short... 2 Checking size of int... 4 Checking size of long... 4 Checking size of long long... 8 Checking size of float... 4 Checking size of double... 8 Checking size of void*... 4 Checking for pthread_create() in C library pthread... yes
Generating config.h with the following settings:
WORDS_BIGENDIAN None ###[bad]### HAVE_LIBPTHREAD 1 SIZEOF_LONG_LONG 8 SIZEOF_LONG 4 WIN32 0 SIZEOF_VOIDP 4 SIZEOF_CHAR 1 SIZEOF_DOUBLE 8 SIZEOF_FLOAT 4 SIZEOF_INT 4 HAVE_GCC_LABELS 1 SIZEOF_SHORT 2
TypeError: int argument required: File "Sconstruct", line 35: configure(env, Configure) # Configure File "/home/isaac/build/yhc-devel/build/configure.py", line 42: config_h_build('config.h', 'config.h.new.in', vals) File "/home/isaac/build/yhc-devel/build/config_h.py", line 21: text = config_h_in.read() % defines
(I'm on powerpc which is big-endian)
Isaac
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Wilkinson wrote:
Can you try going into the .scons_temp subdirectory under whereever you built yhc? In there will be a collection of source code files, executables and text files holding the output. One of them will be the program which determines whether the machine is big endian. If you could run that directly from a consol and tell me what the output is that would be helpful. I have run that program standalone under Solaris and got the correct output.
(It's actually '.sconf_temp', apparently.) That test's executable is missing! This is what actually happened in the failing test (copied from config.log) -- the same error as trying to manually `gcc .sconf_temp/conftest_0.c`: Checking whether byte ordering is bigendian... scons: `.sconf_temp/conftest_0.c' is up to date. gcc -o .sconf_temp/conftest_0 .sconf_temp/conftest_0.o .sconf_temp/conftest_0.o: In function `main': conftest_0.c:(.text+0x14): undefined reference to `ffi_call' collect2: ld returned 1 exit status scons: *** [.sconf_temp/conftest_0] Error 1 Result: failed Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEtlMZHgcxvIWYTTURAl0NAKC2msBnmsTHPtdid8VK8H42mCeC5ACbBJeR OVbaJ3fPcV38j+h+MlWK7t8= =RxW+ -----END PGP SIGNATURE-----
ffi_call? Now that makes no sense at all! The test for big endianess goes no where near libffi... Can you please either delete your yhc directory and start from scratch, or delete .sconf_temp and darcs pull? This will check that you're using the latest code and that scons' configuration caching isn't doing silly things. Cheers, Andrew
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ok, fresh darcs get, and scons... ... Checking whether byte ordering is bigendian... no ... WORDS_BIGENDIAN False ... Ok, that's different, but wrong. I've rewritten the endianness test in C to work (at least for me) and be better commented and more reliable/portable (in my opinion). Can I `darcs send` the change then? (if so, to where, your email address? or the mailing list's? -- there's no darcs "author" file currently) Isaac Andrew Wilkinson wrote:
ffi_call? Now that makes no sense at all! The test for big endianess goes no where near libffi...
Can you please either delete your yhc directory and start from scratch, or delete .sconf_temp and darcs pull? This will check that you're using the latest code and that scons' configuration caching isn't doing silly things.
Cheers, Andrew
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEtmruHgcxvIWYTTURArj7AJkBDKcYmkzW3HShtsN/gOLSxzoyZACfWXTG 0SsN4wmopbUflIPLjo1RjEc= =0ytC -----END PGP SIGNATURE-----
Hi Isaac,
Just send it to the list, since there are about 4 of us who have
access to the repo, and we all tend to commit different bits.
I'll see if I can figure out how to add yhc@ to the author list.
Thanks
Neil
On 7/13/06, Isaac
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Ok, fresh darcs get, and scons...
... Checking whether byte ordering is bigendian... no ... WORDS_BIGENDIAN False ...
Ok, that's different, but wrong. I've rewritten the endianness test in C to work (at least for me) and be better commented and more reliable/portable (in my opinion). Can I `darcs send` the change then? (if so, to where, your email address? or the mailing list's? -- there's no darcs "author" file currently)
Isaac
Andrew Wilkinson wrote:
ffi_call? Now that makes no sense at all! The test for big endianess goes no where near libffi...
Can you please either delete your yhc directory and start from scratch, or delete .sconf_temp and darcs pull? This will check that you're using the latest code and that scons' configuration caching isn't doing silly things.
Cheers, Andrew
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEtmruHgcxvIWYTTURArj7AJkBDKcYmkzW3HShtsN/gOLSxzoyZACfWXTG 0SsN4wmopbUflIPLjo1RjEc= =0ytC -----END PGP SIGNATURE----- _______________________________________________ Yhc mailing list Yhc@haskell.org http://www.haskell.org//mailman/listinfo/yhc
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Neil Mitchell wrote:
Hi Isaac,
Just send it to the list, since there are about 4 of us who have access to the repo, and we all tend to commit different bits.
I'll see if I can figure out how to add yhc@ to the author list.
Darcs manual says: email The _darcs/prefs/email file is used to provide the e-mail address for your repository that others will use when they darcs send a patch back to you. The contents of the file should simply be an e-mail address. Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEtm1NHgcxvIWYTTURAq9iAKC6NtxUfNTuc2blFLSxRPEBLrnbEgCfV/pj gAkZjl1f5ut4/qJlcn5rrf8= =kE5O -----END PGP SIGNATURE-----
Darcs manual says:
email The _darcs/prefs/email file is used to provide the e-mail address for your repository that others will use when they darcs send a patch back to you. The contents of the file should simply be an e-mail address.
Done, see: http://www.cs.york.ac.uk/fp/darcs/yhc-devel/_darcs/prefs/email A darcs pull doesn't seem to pull that information though, so I guess only new repo's will have it - but useful to have. Thanks Neil
participants (4)
-
Andrew Wilkinson -
Isaac -
Neil Mitchell -
Thomas Shackell