From: Dom L. <ci...@ho...> - 2001-01-31 01:06:46
|
Hi everyone, I'm planning to release a wvWare version 0.6.4 tonight. 0.6.4 will be the final release in the 0.6.x series. This raises the question: what's the future for wvWare? Well, as I see it now, I've inherited an unmaintainable mess. I plan on fixing this. How? 1) Header file cleanup. wv.h has too much shit in it. So does wvexporter.h. Only export to the world the necessary functions, enums, and types. It's doubtful that anyone will ever want to call most of these functions. Create wvinternal.h or something like that that won't get installed and #includes wv.h. Make our .c files #include wvinternal.h 2) Reduce the number of wvTrace() and wvError calls significantly. wv is much too verbose right now. 3) Deprecate the XML backend - or at least cease supporting it. The XML-based backend is a beautiful proof-of-concept, but it has proven to be too limiting for my liking. We should try to create actual C programs for wvHtml, wvLaTeX, etc... and thus have much more control over the generated output. 4) Make wv stateful. There are currently too many global and static variables. This really needs to be fixed. wvWare needs to remove all static and global vars in order to really be a true library. Ideas I'm thinking about include adding more state information to the wvParseStruct. 5) Remove cruft/unused files/directories. This also means that we'll need to move around some files. 6) wvExporter. I've finally gotten some help on this from Paul up in Toronto. Hopefully, this part of the wvWare project will move along nicely. 7) Get Dov's work and suggestions/bugfixes into the tree. Currently, we don't handle RTL encodings. 8) Bugfixes, as always. #Hopefuls 9) Rewrite configure.in and the Makefiles. Allow wvWare to be built as a shared library as well as a static lib. 10) Anything else Questions, comments, and support are always welcome. Take care, Dom _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com |
From: F J F. <F.J...@sh...> - 2001-01-31 13:40:19
Attachments:
internal.patch
|
On Tue, 30 Jan 2001, Dom Lachowicz wrote: > 1) Header file cleanup. wv.h has too much shit in it. So does wvexporter.h. > Only export to the world the necessary functions, enums, and types. It's > doubtful that anyone will ever want to call most of these functions. Create > wvinternal.h or something like that that won't get installed and #includes > wv.h. Make our .c files #include wvinternal.h Definitely. And here's a patch which basically changes all (but one) references to wv.h to wvinternal.h (plus some other very minor clean up). Some of these references ought to be reverted once we have a clearer idea of what should be in wv.h and what should be in wvinternal.h... What would be nice also, IMO, is if wv.h itself was put in a separate directory (i.e., wv/include/). And how about installing the header-files in a wv directory (${prefix}/include/wv)? > 9) Rewrite configure.in and the Makefiles. Allow wvWare to be built as a > shared library as well as a static lib. Easy enough to do with automake, which works on unix etc. and cygwin, I believe, though I don't know about MacOS & MSVC etc. What do you mean by "Rewrite configure.in"? Is it just to support shared libraries or do you have other changes in mind too? Regards, Frank Francis James Franklin F.J...@sh... Diodorus the professor of logic died of shame because he could not at once solve a problem put to him in jest by Stilpo. --- Pliny the Elder |
From: Bob F. <bfr...@si...> - 2001-02-01 02:26:32
|
On Wed, 31 Jan 2001, F J Franklin wrote: > > 9) Rewrite configure.in and the Makefiles. Allow wvWare to be built as a > > shared library as well as a static lib. > > Easy enough to do with automake, which works on unix etc. and cygwin, I > believe, though I don't know about MacOS & MSVC etc. I think you are thinking about libtool. Automake is a Makefile.in generation tool. You can use libtool without Automake. I recommend using Automake though. MacOS & MSVC are best served using the compiler vendor's build scheme. Bob ====================================== Bob Friesenhahn bfr...@si... http://www.simplesystems.org/users/bfriesen |
From: F J F. <F.J...@sh...> - 2001-02-01 14:49:01
|
On Wed, 31 Jan 2001, Bob Friesenhahn wrote: > I think you are thinking about libtool. Automake is a Makefile.in > generation tool. You can use libtool without Automake. I recommend > using Automake though. Mea culpa. I do know the difference but I never use them independently... By the way, does anyone know how (if at all possible) to use automake & libtool to create a (i.e., *one*) shared library when the source is in multiple directories? I have a hack-method but it's frustrating... Oh, and: .libs/libwv.so: undefined reference to `cp' .libs/libwv.so: undefined reference to `realcp' .libs/libwv.so: undefined reference to `patterndir' .libs/libwv.so: undefined reference to `insuper' .libs/libwv.so: undefined reference to `ms_strlower' .libs/libwv.so: undefined reference to `erroroutput' .libs/libwv.so: undefined reference to `decode_sprm' .libs/libwv.so: undefined reference to `outputfile' (realcp is declared extern in annotations.c & hyperlink.c) Any ideas? On Wed, 31 Jan 2001, Dom Lachowicz wrote: >> Definitely. And here's a patch which basically changes all (but one) >> references to wv.h to wvinternal.h (plus some other very minor clean up). >> Some of these references ought to be reverted once we have a clearer idea >> of what should be in wv.h and what should be in wvinternal.h... > > I'll take a better look at this in a short while, but it should be ok (only > wvWare.c and wvRTF.c should need to #include wv.h instead of wvinternal.h). Also, thinking about it, wvexporter.h should call wv.h, not wvinternal.h (my bad), and there should be a wvexporterinternal.h (or similar :-) which includes wvexporter.h. Regards, Frank Francis James Franklin F.J...@sh... Diodorus the professor of logic died of shame because he could not at once solve a problem put to him in jest by Stilpo. --- Pliny the Elder |
From: Bob F. <bfr...@si...> - 2001-02-01 19:54:21
|
On Thu, 1 Feb 2001, F J Franklin wrote: > On Wed, 31 Jan 2001, Bob Friesenhahn wrote: > > I think you are thinking about libtool. Automake is a Makefile.in > > generation tool. You can use libtool without Automake. I recommend > > using Automake though. > > Mea culpa. I do know the difference but I never use them independently... > > By the way, does anyone know how (if at all possible) to use automake & > libtool to create a (i.e., *one*) shared library when the source is in > multiple directories? I have a hack-method but it's frustrating... Yes. I do this for ImageMagick. If you use CVS Automake, you can use its convenience library support. This builds a .a library when you can then refer to when you build your shared library. I think there may even be some support for this in the released Automake. Use the target 'noinst_LTLIBRARIES' to list convenience libraries to be built. Bob ====================================== Bob Friesenhahn bfr...@si... http://www.simplesystems.org/users/bfriesen |
From: F J F. <F.J...@sh...> - 2001-02-02 08:56:18
|
On Thu, 1 Feb 2001, Bob Friesenhahn wrote: > Use the target 'noinst_LTLIBRARIES' to list convenience libraries to > be built. Hey! My documentation says that's illegal! Still, if it works don't knock it... Thanks, Frank Francis James Franklin F.J...@sh... Diodorus the professor of logic died of shame because he could not at once solve a problem put to him in jest by Stilpo. --- Pliny the Elder |
From: Bob F. <bfr...@si...> - 2001-02-02 13:43:10
|
On Fri, 2 Feb 2001, F J Franklin wrote: > On Thu, 1 Feb 2001, Bob Friesenhahn wrote: > > Use the target 'noinst_LTLIBRARIES' to list convenience libraries to > > be built. > > Hey! My documentation says that's illegal! I think that just means you need more recent documentation. :-) I am using Automake 1.4a at the moment. I have sent you sample Makefile.am files in a seperate email (too big for list). Bob ====================================== Bob Friesenhahn bfr...@si... http://www.simplesystems.org/users/bfriesen |
From: F J F. <F.J...@sh...> - 2001-02-02 11:12:23
Attachments:
am_add.tgz
am_conf.patch
|
Hi Everyone, Okay, I've attached a framework for building shared libraries using automake & libtool. The archive adds mostly Makefile.am files and the patch is to configure.in, config.h.in & version.c (see below). Just: patch -p0 < am_conf.patch tar zxf am_add.tgz cd wv aclocal automake autoconf ./configure [OPTIONS] make make install (Start with a clean distribution or you may get autoheader complaints for reasons which escape me.) It's not finished but it does compile & install (for me on Linux RH7 & LinuxPPC 2000), though I haven't tested whether it *works*. I'm going to work on it over the weekend, particularly with regard to autoconf, conditional compilation, etc. My biggest concern with it is the following: > .libs/libwv.so: undefined reference to `cp' > .libs/libwv.so: undefined reference to `realcp' > .libs/libwv.so: undefined reference to `patterndir' > .libs/libwv.so: undefined reference to `insuper' > .libs/libwv.so: undefined reference to `ms_strlower' > .libs/libwv.so: undefined reference to `erroroutput' > .libs/libwv.so: undefined reference to `decode_sprm' > .libs/libwv.so: undefined reference to `outputfile' I'm a little baffled over why compilation ever succeeded without these. I have added patterndir() and added *fake* declarations for the others in wv/version.c, but this *really* needs to be sorted out. Comments, queries, suggestions & explanations all welcome... Regards, Frank Francis James Franklin F.J...@sh... Diodorus the professor of logic died of shame because he could not at once solve a problem put to him in jest by Stilpo. --- Pliny the Elder |