Re: [Chicken-users] chicken-setup
hi, On Tue, Jul 15, 2008 at 09:54:30AM -0300, Mario Domenech Goulart wrote: > Maybe we can do this automagically. We can keep a hash (e.g., md5, > sha) of the repository metadata file. chicken-setup always downloads > the hash file (which is small) and compares with the local copy. If > the remote and local hashes are different, chicken-setup fetches the > remote (most recent) repository metadata file and its hash. If the > remote and the local hash are the same, chicken-setup uses the local > metadata file. why not just use the normal http if-modified-since mechanism? bye, hans. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken-setup
2008/7/15 Shawn Rutledge <[EMAIL PROTECTED]>: > On Mon, Jul 14, 2008 at 6:01 PM, Ivan Raikov <[EMAIL PROTECTED]> wrote: >> The idea is basically to isolate all of the general procedures for >> e.g. installation and compilation, which once written would probably >> stay relatively unchanged, and only modify the frontend as >> chicken-setup policies evolve. We could also think about having >> different frontends, e.g. for use with different package building >> tools. > > This sounds good so far. > > So an egg could include a custom setup script, or else it would be > auto-generated from the .meta file at installation time and therefore > the egg is not required to provide it, right? > > On Tue, Jul 15, 2008 at 12:11 AM, Peter Bex <[EMAIL PROTECTED]> wrote: >> I don't think this can be solved automatically (unless we want to >> recreate Autotools or CMake) so what is needed is a way to override or >> add to existing search paths by passing switches to chicken-setup, >> which it then can pass on to the compiler. Example: >> >> chicken-setup foo.egg -I /opt/foo/include -L /opt/foo/lib > > That could be a last-ditch way to solve problems but I would hope most > users wouldn't need to do that for most eggs. > > Is there anything wrong with putting extra -I's and -L's in the meta > file, with some possible guesses the egg developer can think of, where > a particular library or include might be located? And chicken-setup > could append the usual suspects automatically, like /usr/include, > /usr/local/include etc. > > (library foo-wrapper > (version 1.4) > (make (foo-wrapper.scm) (compile -O2 -d0 -s foo-wrapper.scm > -L/usr/lib/foo -L/usr/include/foo -ldl -lfoo -lchicken > > One problem I could think of is the case where the user has multiple > versions of the same library, or is cross-compiling, in which case the > default paths, or the paths suggested in the meta file, could be > misleading. I guess he'd have to specify the -I and -L somehow, as > you suggest. If the user does that, then chicken-setup would not > include the default paths, or at least would put the provided paths > first. > > Or somehow the meta file could suggest that libfoo.so might be located > in a directory called foo-1.0, somewhere, and chicken-setup could > expand that to -L/usr/lib/foo-1.0 -L/usr/local/lib/foo-1.0 etc. > > But the ability to cross-compile eggs is something I need to test > soon; sounds like it's pretty cool already. I'm working on a bitbake > recipe for chicken for OpenMoko (I'm still a newbie with that) and am > wondering if it's going to be possible to get bitbake to compile all > the eggs too, and make ipk's for all of them, hopefully either > semi-automatically or I can come up with a way to generate recipes > automatically from the meta files, or something. Hi, Another case is when we use pkg-config as in `pkg-config --cflags --libs pangocairo`. Thu ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken-setup
On Mon, Jul 14, 2008 at 6:01 PM, Ivan Raikov <[EMAIL PROTECTED]> wrote: > The idea is basically to isolate all of the general procedures for > e.g. installation and compilation, which once written would probably > stay relatively unchanged, and only modify the frontend as > chicken-setup policies evolve. We could also think about having > different frontends, e.g. for use with different package building > tools. This sounds good so far. So an egg could include a custom setup script, or else it would be auto-generated from the .meta file at installation time and therefore the egg is not required to provide it, right? On Tue, Jul 15, 2008 at 12:11 AM, Peter Bex <[EMAIL PROTECTED]> wrote: > I don't think this can be solved automatically (unless we want to > recreate Autotools or CMake) so what is needed is a way to override or > add to existing search paths by passing switches to chicken-setup, > which it then can pass on to the compiler. Example: > > chicken-setup foo.egg -I /opt/foo/include -L /opt/foo/lib That could be a last-ditch way to solve problems but I would hope most users wouldn't need to do that for most eggs. Is there anything wrong with putting extra -I's and -L's in the meta file, with some possible guesses the egg developer can think of, where a particular library or include might be located? And chicken-setup could append the usual suspects automatically, like /usr/include, /usr/local/include etc. (library foo-wrapper (version 1.4) (make (foo-wrapper.scm) (compile -O2 -d0 -s foo-wrapper.scm -L/usr/lib/foo -L/usr/include/foo -ldl -lfoo -lchicken One problem I could think of is the case where the user has multiple versions of the same library, or is cross-compiling, in which case the default paths, or the paths suggested in the meta file, could be misleading. I guess he'd have to specify the -I and -L somehow, as you suggest. If the user does that, then chicken-setup would not include the default paths, or at least would put the provided paths first. Or somehow the meta file could suggest that libfoo.so might be located in a directory called foo-1.0, somewhere, and chicken-setup could expand that to -L/usr/lib/foo-1.0 -L/usr/local/lib/foo-1.0 etc. But the ability to cross-compile eggs is something I need to test soon; sounds like it's pretty cool already. I'm working on a bitbake recipe for chicken for OpenMoko (I'm still a newbie with that) and am wondering if it's going to be possible to get bitbake to compile all the eggs too, and make ipk's for all of them, hopefully either semi-automatically or I can come up with a way to generate recipes automatically from the meta files, or something. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] hygienic branch basically working
Works great now. Sorry for the delay in feedback, I was out of town for a couple weeks. I will dive in again shortly. This module stuff is complicated, isn't it. On Tue, Jul 15, 2008 at 7:48 AM, felix winkelmann <[EMAIL PROTECTED]> wrote: > On Fri, Jul 11, 2008 at 9:38 PM, Jim Ursetto <[EMAIL PROTECTED]> wrote: >> >> Hi Felix. The behavior below doesn't seem right. An unimported >> binding is seen within a module in both compiled and interpreted code. >> However a binding (pretty-print) in the extras unit behaves as >> expected. >> > > Please try the current svn head. It should work now as expected. > > > cheers, > felix > ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] #include in foreign-parse
On Sat, Jul 5, 2008 at 8:25 PM, minh thu <[EMAIL PROTECTED]> wrote: > > No problem, everything is fine. > > (But how do I install a local .egg ? chicken-setup complains the .egg > is not in /tmp/chicken-... ) > > Then, since the somefile.h ships with the library to bind, it makes sense, > to replace > > #include "somefile.h" > > with > > #include > > no more put it in the .egg, and assume the library is already installed. > > But now, when installing the egg, I've got > > Error: during expansion of (foreign-parse ...) - can not open include > file: "somefile.h" > > I think the problem is because of the change "somefile.h" > , but I'm not sure. > > The header is in /usr/local/include/, maybe sudo chicken-setup does not see > it ? > That's right. `foreign-parse' will follow the #include and try to generate bindings from it's contents. Since the header is not in the egg anymore (and foreign-parse does not search default include paths), the egg isn't found. You can wrap the include-line into #ifndef CHICKEN #include ... #endif or put the #include into a `foreign-declare' section. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: getopt, getopt_long?
William Xu <[EMAIL PROTECTED]> writes: > "felix winkelmann" <[EMAIL PROTECTED]> writes: > >> I think chicken-setup should NOT duplicate functionality that >> modern packaging tools provide. Dpkg and portage will always >> do a better job at that, and it would be more worthwhile to push >> for adoption of eggs into these packaging systems (which, IIRC, >> Ivan already does with debianizing several eggs). > > I don't know if i understand correctly. If that means making each egg a > debian package, oh Jesus!! That'll spawn many debian eggs. And > considering there are that many linux distributions, it's a big burden.. > not to mention non-linux platforms. It is a big burden anyway, since it violates hierarchy: installation under PREFIX is managed, and Chicken interferes with it, the easiest way to resolve conflict is to provide build-time configurational parameter to make eggs install under separate directory. -- CE3OH... ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken-setup
Hi folks, On Tue, 15 Jul 2008 14:46:33 +0200 "felix winkelmann" <[EMAIL PROTECTED]> wrote: > An interesting question is where to get the meta-information. I > think a good approach would be to have it locally, but not including > the build-instructions. An "update" command (to chicken-setup or in > whatever manner) could update the local tree with meta-information > from a central location. Maybe we can do this automagically. We can keep a hash (e.g., md5, sha) of the repository metadata file. chicken-setup always downloads the hash file (which is small) and compares with the local copy. If the remote and local hashes are different, chicken-setup fetches the remote (most recent) repository metadata file and its hash. If the remote and the local hash are the same, chicken-setup uses the local metadata file. Best wishes, Mario ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] hygienic branch basically working
On Fri, Jul 11, 2008 at 9:38 PM, Jim Ursetto <[EMAIL PROTECTED]> wrote: > > Hi Felix. The behavior below doesn't seem right. An unimported > binding is seen within a module in both compiled and interpreted code. > However a binding (pretty-print) in the extras unit behaves as > expected. > Please try the current svn head. It should work now as expected. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken-setup
On Tue, Jul 15, 2008 at 3:01 AM, Ivan Raikov <[EMAIL PROTECTED]> wrote: > > What I would like to see is a two-tier installation system that > consists of an interpreter for compilation/installation scripts, and a > chicken-setup frontend. The interpreter should know three things: > where to get source tarballs (source locations), rules that specify > how to compile sources into executables, and where to install files > (installation locations). The frontend would read in an egg > specification (.meta file) supplant it with defaults such as source > locations, and provide a complete installation specification to the > interpreter. > An interesting question is where to get the meta-information. I think a good approach would be to have it locally, but not including the build-instructions. An "update" command (to chicken-setup or in whatever manner) could update the local tree with meta-information from a central location. That way a lot of information for, say, listing available eggs, possible upgrades, etc. can be performed locally. Build-instructions (make-rules) on the other hand are tied to the sources and may change frequently. The meta-info-tree could be autogenerated periodically (or even created from a local svn checkout). cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken-setup
On Tue, 15 Jul 2008 09:11:20 +0200 Peter Bex <[EMAIL PROTECTED]> wrote: > I don't think this can be solved automatically (unless we want to > recreate Autotools or CMake) so what is needed is a way to override or > add to existing search paths by passing switches to chicken-setup, > which it then can pass on to the compiler. Example: > > chicken-setup foo.egg -I /opt/foo/include -L /opt/foo/lib Can't it be done with the -csc-option option? Best wishes, Mario ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken-setup
On Tue, Jul 15, 2008 at 10:01:52AM +0900, Ivan Raikov wrote: >The frontend would also have a list of default installation > locations for each type of file (library, program, etc.). Using these > defaults, the frontend could for example generate the following > installation script: > > ((source-locations "." "/home/user/tmp/chicken-4-user-downloads" > "ftp://call/cc.org/eggs/4";) > (installation-locations ((library "/usr/lib/chicken/4") >(program "/usr/bin/") >(doc "/usr/share/doc"))) > (library treap >(make (treap.scm) ;; source files > (compile -O2 -d0 -s treap.scm -ldl -lchicken > ;; compilation commands > > This specification would be passed to the interpreter, along with > commands such as "compile" "install" "uninstall", etc. > >The idea is basically to isolate all of the general procedures for > e.g. installation and compilation, which once written would probably > stay relatively unchanged, and only modify the frontend as > chicken-setup policies evolve. We could also think about having > different frontends, e.g. for use with different package building > tools. Sounds good so far! One other thing that needs consideration is how to handle system-specific things like include/library paths and possibly names of libraries, for building bindings to C libraries. I don't think this can be solved automatically (unless we want to recreate Autotools or CMake) so what is needed is a way to override or add to existing search paths by passing switches to chicken-setup, which it then can pass on to the compiler. Example: chicken-setup foo.egg -I /opt/foo/include -L /opt/foo/lib Or possibly something slightly smarter that knows about lpaths and rpaths for libraries. This makes it easier to install eggs on systems without having to hardcode paths in setup files. This means it would not be necessary anymore to untar an egg file, go in and hack the setup file and then rebuild, making the process of installing egg files much more natural and user-friendly. Cheers, Peter -- http://sjamaan.ath.cx -- "The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music." -- Donald Knuth pgpsxCNdWZCqb.pgp Description: PGP signature ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
