Thread: RE: [Plib-devel] Releasing PLIB 1.2 *soon*.
Brought to you by:
sjbaker
Menu
▾
▴
plib-devel
|
From: Dave M. <Dav...@dy...> - 2000-03-29 16:45:20
|
> > I am a bit confused about this.. > > The MSVC project files in CVS work well. > > Oh? Now I'm puzzled. Maybe Dave checked in those files himself. > > I'll check *carefully* before I mess with it. > Hi Steve, I checked in the MSVC project files for PLIB. The project files I sent you are for plib_examples since I didn't have CVS access to that. > > You will base 1.2 on what is in CVS, wont you? > > Absolutely...but since it's a CVS and can potentially be changed > right up to the last 10 seconds before I make an official 1.2 > release out of it - I need to be sure that everyone can agree on > a short-term "feature" freeze while the last few wrinkles are > ironed out. > i'd like to update a few of the model loaders before the freeze. i'll try to wrap them up this week. --Dave McClurg |
|
From: Dave M. <Dav...@dy...> - 2000-03-30 17:03:57
|
Steve Baker Wrote: > I wanted to mention that I'd like to release PLIB 1.2 (a stable > release) sometime soon. I have a couple of mods of my own to > put in - if anyone else needs to commit anything or knows of > any significant problems that need fixing - please let me know > so that we can arrange to catch all of these prior to release. > Sam Stickland Wrote: >The DLL changes simply require a: > >#ifdef WIN32 > #define PU_EXPORT __dllspec(dllexport) >#else > #define PU_EXPORT >#endif > >in a common header file, and then PU_EXPORT has to be added to every >function and variable prototype/declaration (after the return type, but >before the prototype). And, of course, some matches project files to >generate the DLLs (I can supply VC++ version 6) (although it's probably best >to supply all new project files VC++ being what it is). > >I can supply a patch for the DLL and .so stuff - I'm not sure if it's worth >it for the interface resizing stuff. > I would really like to see the patch for DLL stuff make it into PLIB 1.2 Can I go ahead and add that? I'll use PLIB_EXPORT instead of PU_EXPORT and apply the change to all of PLIB. Each header file would have the following: /* Some compilers use a special export keyword */ #ifndef PLIB_EXPORT # ifdef __BEOS__ # if defined(__GNUC__) # define PLIB_EXPORT __declspec(dllexport) # else # define PLIB_EXPORT __declspec(export) # endif # else # ifdef WIN32 # define PLIB_EXPORT __declspec(dllexport) # else # define PLIB_EXPORT # endif # endif #endif This is the only way i know of that a non-opensource app can use PLIB under BeOS or WIN32 without creating a branch which would be a headache to maintain. --Dave McClurg |
|
From: Steve B. <sjb...@ai...> - 2000-03-31 07:07:06
|
> Dave McClurg wrote: > Sam Stickland Wrote: > >The DLL changes simply require a: > > > >#ifdef WIN32 > > #define PU_EXPORT __dllspec(dllexport) > >#else > > #define PU_EXPORT > >#endif > I would really like to see the patch for DLL stuff make it into PLIB 1.2 > Can I go ahead and add that? I'll use PLIB_EXPORT instead of PU_EXPORT and > apply the change to all of PLIB. Each header file would have the following: I'm really opposed to this. 1) It makes an ugly mess of the source code. 2) There is no sense in using PLIB as a shared library and encouraging people to do so will greatly increase my maintenance burden. Please don't add it to the CVS. > This is the only way i know of that a non-opensource app > can use PLIB under BeOS or WIN32 without creating a branch > which would be a headache to maintain. That's certainly not the case. Read the LGPL license. (Notice this is *L*GPL not regular GPL). -- Steve Baker http://web2.airmail.net/sjbaker1 sjb...@ai... (home) http://www.woodsoup.org/~sbaker sj...@ht... (work) |
|
From: Eero P. <epa...@ko...> - 2000-03-31 07:24:42
|
Steve Baker wrote: > > > Dave McClurg wrote: > > > Sam Stickland Wrote: > > >The DLL changes simply require a: > > > > > >#ifdef WIN32 > > > #define PU_EXPORT __dllspec(dllexport) > > >#else > > > #define PU_EXPORT > > >#endif > > > I would really like to see the patch for DLL stuff make it into PLIB 1.2 > > Can I go ahead and add that? I'll use PLIB_EXPORT instead of PU_EXPORT and > > apply the change to all of PLIB. Each header file would have the following: > > I'm really opposed to this. > > 1) It makes an ugly mess of the source code. > > 2) There is no sense in using PLIB as a shared library and encouraging > people to do so will greatly increase my maintenance burden. > > Please don't add it to the CVS. > > > This is the only way i know of that a non-opensource app > > can use PLIB under BeOS or WIN32 without creating a branch > > which would be a headache to maintain. > > That's certainly not the case. Read the LGPL license. > (Notice this is *L*GPL not regular GPL). > As the LGPL requires that the user must be able to relink the application with a modified version of the library, I for one will not use any LGPL libraries with my application, unless they can be used as dynamically loadable libraries. (which will trivially allow for the "relinking") If the library license is there just inorder to get updates/fixes back to the main distribution, I presonally don't think that LGPL is the best way of doing that. Notice, that I am still using the old "free" version of PUI, because I can simply compile it in. (and I did submit at least one bug fix for it...) Eero |
|
From: Paul B. <pbl...@di...> - 2000-03-31 16:36:30
|
Steve Baker says: > > I'm really opposed to this. > > 1) It makes an ugly mess of the source code. > > 2) There is no sense in using PLIB as a shared library and encouraging > people to do so will greatly increase my maintenance burden. > > Please don't add it to the CVS. I agree with Steve on this. Making shared libraries out of C++ class libraries is asking for a large amount of hurt. Especially with all of the SSG_API (or other) preprocessor macros that would be required. Paul |
|
From: Dave M. <Dav...@dy...> - 2000-03-31 17:22:13
|
Eero wrote: > As the LGPL requires that the user must be able to relink > the application with a modified version of the library, > I for one will not use any LGPL libraries with my application, > unless they can be used as dynamically loadable libraries. > (which will trivially allow for the "relinking") > exactly. -sigh-. but i understand steve's point of view and will continue to contribute to plib. my choices are: 1) supply all my object files with my release 2) do a last minute branch of plib with DLL support both are not ideal but it's worth it to use PLIB any other suggestions? thanks--Dave McClurg |
|
From: Steve B. <sjb...@ai...> - 2000-04-01 06:08:58
|
> Dave McClurg wrote:
>
> Eero wrote:
> > As the LGPL requires that the user must be able to relink
> > the application with a modified version of the library,
> > I for one will not use any LGPL libraries with my application,
> > unless they can be used as dynamically loadable libraries.
> > (which will trivially allow for the "relinking")
> >
> exactly. -sigh-. but i understand steve's point of view
> and will continue to contribute to plib.
> my choices are:
> 1) supply all my object files with my release
> 2) do a last minute branch of plib with DLL support
> both are not ideal but it's worth it to use PLIB
> any other suggestions?
The basic requirement is that your end user can (hypothetically)
replace the PLIB you ship with a newer version if he wants
to at some time in the future without having to buy a new
copy of your code or ask you to do it, etc, etc.
The rule is stated like that for a VERY good reason. It wants
to ensure that anyone who has the OpenSourced library (even
if it's a part of a commercial product) can still fix bugs
in it for themselves using the source code. I need that
because I expect a continuing benefit to me of all those
commercial product users fixing my bugs for me for free.
So, if the library is a DLL, he can do that - but there is a
good chance that if he does, the program will crash because
of the C++ issues.
One alternative is to provide all the '.o' files ('.obj' for
Windoze) and let the user rerun the linker to change out
the PLIB library. This still won't work in practice because
of the C++ issues.
The only *useful* alternative is to ship the entire source code -
but for a commercial product, this isn't generally acceptable.
--
Steve Baker http://web2.airmail.net/sjbaker1
sjb...@ai... (home) http://www.woodsoup.org/~sbaker
sj...@ht... (work)
|
|
From: Eero P. <epa...@ko...> - 2000-04-01 08:45:14
|
Steve Baker wrote: > > So, if the library is a DLL, he can do that - but there is a > good chance that if he does, the program will crash because > of the C++ issues. > I really don't yet know if this would work. Almost certainly it would only work within a certain family of compilers. Anyways I think it would satisfy at least the letter of the LGPL. (And it would not be any worse than distributing application .o files). Btw I am not 100% sure how inline functions behave regarding LGPL. Certainly they cannot be updated if the "client program" is not distributed as source code. (I know the license mentions inline funcs) Assuming that this could be implemented for WIN32 with an external .def file, would you include the .def file into plid distribution? Eero |
|
From: Steve B. <sjb...@ai...> - 2000-04-01 14:51:28
|
Eero Pajarre wrote:
>
> Steve Baker wrote:
> >
>
> > So, if the library is a DLL, he can do that - but there is a
> > good chance that if he does, the program will crash because
> > of the C++ issues.
> >
>
> I really don't yet know if this would work. Almost certainly
> it would only work within a certain family of compilers.
The problem is with C++ and DLL's (or '.so's in UNIX/Linux)
is that any slight change to the C++ header file will generally
result in a new library module that will die when linked to
a program that was compiled with the old header.
That causes endless problems for the poor library maintainer
because he'll get lots of emails of the form "PLIB sucks -
it keeps crashing."...the problem being that someone upgraded
PLIB (either accidentally whilst installing something else
or on purpose) - and didn't recompile *all* the programs
that refer to it.
I'm absolutely adamant that I'm not going there. PLIB support
already takes up *WAY* too much of my time.
You are at liberty (of course) to take a copy of PLIB, change it
to create DLL's, call it something slightly different (PLIBDLL
or something) and deal with the maintenance calls for that new
package yourself.
> Anyways I think it would satisfy at least the letter
> of the LGPL. (And it would not be any worse than
> distributing application .o files).
> Btw I am not
> 100% sure how inline functions behave regarding
> LGPL. Certainly they cannot be updated if the
> "client program" is not distributed as source code.
> (I know the license mentions inline funcs)
LGPL says:
"If such an object file uses only numerical parameters, data
structure layouts and accessors, and small macros and small inline
functions (ten lines or less in length), then the use of the object
file is unrestricted, regardless of whether it is legally a derivative
work."
...so you shouldn't have a problem here.
> Assuming that this could be implemented for WIN32
> with an external .def file, would you include the
> .def file into plid distribution?
If I do that, Windoze users will build DLL's and I'll
get into the whole support rat's nest.
I'm sorry to seem unhelpful about this - but I'm absolutely
not going to do anything to PLIB that makes it harder to
maintain.
But really, you should stick with a staticly linked PLIB
and offer the '.o'/'.obj' files for your application.
Look at the problem carefully:
The relevent section of the LGPL says:
"...linking a "work that uses the Library" with the Library
creates an executable that is a derivative of the Library (because it
contains portions of the Library), rather than a "work that uses the
library". The executable is therefore covered by this License.
Section 6 states terms for distribution of such executables."
...and section 6 says:
"6. As an exception to the Sections above, you may also compile or
link a "work that uses the Library" with the Library to produce a
work containing portions of the Library, and distribute that work
under terms of your choice, provided that the terms permit
modification of the work for the customer's own use and reverse
engineering for debugging such modifications."
"You must give prominent notice with each copy of the work that the
Library is used in it and that the Library and its use are covered by
this License. You must supply a copy of this License." ....
Then, it goes on to say that you must provide source for the library
along with either .o/.obj's for the application - or the source code
for the application....although you can either:
* Distribute those files with the application ...OR...
* "Accompany the work with a written offer, valid for at least
three years, to give the same user the {object files or source code}, for
a charge no more than the cost of performing this distribution.
* Give access to those files on a web site or something but only if
that's how the application was originally distributed.
* Mention that the user already has all those files (eg in the case
of the GNU math library or something).
It seems to me that all you *really* need to do is to put a note in
the manual or 'README' file that says something to the effect of:
"This package makes use of 'PLIB' - which is licensed under the
Library GNU Public License. Under the terms of that license,
you are entitled to request certain materials that would allow
you to re-link this package using a modified version of PLIB.
This offer is valid for three years only - and you will be
charged for the cost of distributing those materials. Please
write to the address below if you would like to take advantage
of this facility."
...then you make a pile of about 50 floppies with the .o files and
PLIB sources, put them in a cupboard somewhere and forget about them.
The nebulous "cost of distributing" will put off the idly curious
and if someone really does want a copy - charge them whatever it costs
you to get an employee to answer the mail, pick up a floppy from the
cupboard and post it to the customer. You can charge the actual
cost of doing this - so if your internal hourly rate for your staff
is $45 per hour and the cost of the floppy is $1 and the postage
$2 then you can demand $50 for this service. If a ton of people
decide to take you up on it for some arcane reason, you won't lose
out.
I think you are making way to big a deal about this - it's a
no-brainer, really.
--
Steve Baker http://web2.airmail.net/sjbaker1
sjb...@ai... (home) http://www.woodsoup.org/~sbaker
sj...@ht... (work)
|
|
From: Eero P. <epa...@ko...> - 2000-04-01 20:37:54
|
Steve Baker wrote: > > Eero Pajarre wrote: > > > > Steve Baker wrote: > > > > > > > > So, if the library is a DLL, he can do that - but there is a > > > good chance that if he does, the program will crash because > > > of the C++ issues. > > > > > > > I really don't yet know if this would work. Almost certainly > > it would only work within a certain family of compilers. > > The problem is with C++ and DLL's (or '.so's in UNIX/Linux) > is that any slight change to the C++ header file will generally > result in a new library module that will die when linked to > a program that was compiled with the old header. > > That causes endless problems for the poor library maintainer > because he'll get lots of emails of the form "PLIB sucks - > it keeps crashing."...the problem being that someone upgraded > PLIB (either accidentally whilst installing something else > or on purpose) - and didn't recompile *all* the programs > that refer to it. > > I'm absolutely adamant that I'm not going there. PLIB support > already takes up *WAY* too much of my time. > > You are at liberty (of course) to take a copy of PLIB, change it > to create DLL's, call it something slightly different (PLIBDLL > or something) and deal with the maintenance calls for that new > package yourself. > I am in the "lucky" position that I expect that my program will have a small distribution. (And thus it will be expensive). The typical client will also get an maintenance package. Obviously the client is not allowed to mess with those application files which are not specifically allowed. "Recovery services available at $100/hour" So if I bundle PLIB then I am not worried about possible dll problems ;-) In any case this still speculation, Currently I only use the old "very free" PUI, not so much for license reasons, but because my feature requirements wree satisfied with that version. Eero |
|
From: Paul B. <pbl...@di...> - 2000-03-31 17:26:15
|
You should be able to write a script to generate a .def file from the source tree if you really want a dll. I've been doing this to use Lua as a win32 dll for a while now. Lua is pure C though, so your script would have to be a bit more "interesting." Paul -----Original Message----- From: Dave McClurg [mailto:Dav...@dy...] Sent: Friday, March 31, 2000 11:16 AM To: 'pli...@li...' Subject: RE: [Plib-devel] Releasing PLIB 1.2 *soon*. Eero wrote: > As the LGPL requires that the user must be able to relink > the application with a modified version of the library, > I for one will not use any LGPL libraries with my application, > unless they can be used as dynamically loadable libraries. > (which will trivially allow for the "relinking") > exactly. -sigh-. but i understand steve's point of view and will continue to contribute to plib. my choices are: 1) supply all my object files with my release 2) do a last minute branch of plib with DLL support both are not ideal but it's worth it to use PLIB any other suggestions? thanks--Dave McClurg |
|
From: Steve B. <sjb...@ai...> - 2000-03-31 07:00:47
|
> Dave McClurg wrote: > I checked in the MSVC project files for PLIB. > The project files I sent you are for plib_examples > since I didn't have CVS access to that. Ah! That explains it. I really need to get around to putting the example progs on CVS. Maybe for 1.3. > i'd like to update a few of the model loaders before the freeze. > i'll try to wrap them up this week. OK. That'll be perfect. -- Steve Baker http://web2.airmail.net/sjbaker1 sjb...@ai... (home) http://www.woodsoup.org/~sbaker sj...@ht... (work) |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X