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 considered using cmake or jam instead of autoconf ? I'm not saying I know it to be better, but it just seems like it can't get any worse either (besides simplicity, it definitely could be faster, the current configure business is a resource hog, timewise).
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 go for the async interface .
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.
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.
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 over.
It hasn't actually reached the stage "useful" yet; the implementation consists mostly of some basic framework stuff, the rest is just design. :-)
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.
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 interest faded. I might actually be interested in looking at that again.
Isn't this just about what jam and/or cmake try to do too?
cmake doesn't try to replace make, it actually generates makefiles. jam doesn't try to replace autoconf, it uses autoconf.
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 would like to get away from having to create a Makefile in every subdirectory.
jam doesn't try to replace autoconf, it uses autoconf.
Erm... I didn't know that. I've seen it used in a C++ project with little dependencies. But, yes, making it depend on autoconf again is not helping at all.
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 subdirectory.
With craft, you don't have to put a Craftfile in every directory. But you can if you like to, and if you do you _only_ have to put stuff which is specific to that directory in it.
Erm... I didn't know that. I've seen it used in a C++ project with little dependencies. But, yes, making it depend on autoconf again is not helping at all.
If you have little or no dependencies, you can use it without autoconf. But that is true of make as well.
pike-devel@lists.lysator.liu.se
-
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum -
Martin Nilsson (Opera Mini - AFK!) ＠ Pike (-) developers forum
-
Stephen R. van den Berg