Ok, pike-git.lysator.liu.se:craft.git is now available. I have some
uncommitted work too, maybe I'll clean it up and commit it later.
It hasn't actually reached the stage "useful" yet; the implementation
consists mostly of some basic framework stuff, the rest is just
design. :-)
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
>I could move the repository to pike-git.lysator.liu.se (it's currently
>on svn.lysator.liu.se) if there is interrest in it.
Well, it's not the highest on my list of priorities, but it sounds useful,
so please copy it ov
>There's nothing inherently wrong with that, I think, except that Makefiles
>don't do well in a hierarchical setting;
Which is one of the main disadvantages of make that craft adresses.
>and yes, I would tend to agree,
>one would like to get away from having to create a Makefile in every
>subdir
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
>cmake doesn't try to replace make, it actually generates makefiles.
There's nothing inherently wrong with that, I think, except that Makefiles
don't do well in a hierarchical setting; and yes, I would tend to agree,
one
cmake doesn't try to replace make, it actually generates makefiles.
jam doesn't try to replace autoconf, it uses autoconf.
Martin Nilsson (Opera Mini - AFK!) @ Pike (-) developers forum wrote:
>We have considered not using autoconf, yes. We started on our own
>project called "craft" (basically merging make and autoconf so that
>you could have depndencies on not only between files but on other
>resources as well), but i
I could move the repository to pike-git.lysator.liu.se (it's currently
on svn.lysator.liu.se) if there is interrest in it.
We have considered not using autoconf, yes. We started on our own
project called "craft" (basically merging make and autoconf so that
you could have depndencies on not only between files but on other
resources as well), but interest faded. I might actually be
interested in looking at that again.
Stephen R. van den Berg wrote:
>Just in case someone happens to be working on it, I'm in the process of
>implementing a native interface to libusb-1.0 from within Pike.
Any implementation advice or feature requests are welcome.
So far, I've already decided to skip/drop the blocking interface, and
Just in case someone happens to be working on it, I'm in the process of
implementing a native interface to libusb-1.0 from within Pike.
The sad part is that actually programming the interface is not that much
work, generating proper configure.in files *is* however a big PITA.
Has anyone ever consi
11 matches
Mail list logo
