You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2000/12/22 09:33:45 UTC
Re: cvs commit: apr apr.dsp apr.mak
Whoa...
> brane 00/12/21 15:02:36
>
> Modified: . apr.dsp apr.mak
> Log:
> Don't export symbols from static library.
Please watch out, you broke the build.
I understand that it -appears- that apr.dsp is the static
library generator. At the moment, it's a comprimize, and
if we plan to move forward, we have a nasty issue to deal
with...
The list of files to build into apr is in apr.dsp. The
libapr.dsp only generates a dll of that same file.
The comprimize to date was to build a statically linkable
library, with naked symbols hanging out. Certainly we
can't do that forever, so lets begin discussion of some
sane way to cope with two duplicate .dsp files, one that
creates a lib, one that creates a dll (note, we cannot
use the 4-flavor .dsp here, since all flavors need the
same kind of target, e.g. all .dll's or all lib's.)
Re: cvs commit: apr apr.dsp apr.mak
Posted by Branko Čibej <br...@xbc.nu>.
Karl Fogel wrote:
> Branko =?ISO-8859-2?Q?=C8ibej?= <br...@xbc.nu> writes:
>
>> I know this means editing MSVC-generated files, but I've found this much
>> easier to do than trying to maintain non-trivial projects through the
>> GUI. The only caveat is that the generated .dsp's must have DOS-like
>> "\r\n" line endings.
>
>
> Pointer: Edit with a recent version of FSF Emacs and this won't be a
> problem, it will do the newline stuff for you (or maybe XEmacs has
> gotten this right for years, I don't know).
How else do you think I've been doing it? :-)
--
Brane Čibej
home: <br...@xbc.nu> http://www.xbc.nu/brane/
work: <br...@hermes.si> http://www.hermes-softlab.com/
ACM: <br...@acm.org> http://www.acm.org/
Re: cvs commit: apr apr.dsp apr.mak
Posted by Karl Fogel <kf...@galois.collab.net>.
Branko =?ISO-8859-2?Q?=C8ibej?= <br...@xbc.nu> writes:
> I know this means editing MSVC-generated files, but I've found this much
> easier to do than trying to maintain non-trivial projects through the
> GUI. The only caveat is that the generated .dsp's must have DOS-like
> "\r\n" line endings.
Pointer: Edit with a recent version of FSF Emacs and this won't be a
problem, it will do the newline stuff for you (or maybe XEmacs has
gotten this right for years, I don't know).
-K
Re: cvs commit: apr apr.dsp apr.mak
Posted by Branko Čibej <br...@xbc.nu>.
William A. Rowe, Jr. wrote:
>> From: Branko Čibej [mailto:brane@xbc.nu]
>> Sent: Thursday, December 28, 2000 10:47 AM
>>
>> William A. Rowe, Jr. wrote:
>>
>>> Whoa...
>>>
>>>> brane 00/12/21 15:02:36
>>>>
>>>> Modified: . apr.dsp apr.mak
>>>> Log:
>>>> Don't export symbols from static library.
>>>
>>>
>>> Please watch out, you broke the build.
>>
>> Oops, my aplologies. "I just naturally assumed ..." Will be
>> more careful next time.
>
>
> Not a problem ... this just happened to occur as we were about
> to roll a beta :-)
>
> The issue remains :-/ There were three ideas all along of how
> to do this; have two MSVC projects, apr and libapr that list all
> the modules (and have to change in sync), one project with both
> models (and this leads to a nightmare when that workspace
> includes static + dynamic linkage to the library, as Apache
> does), and finally, fly the second project from the first, perhaps
> even use a script to rewrite the second with all the modules
> contained in the first for building.
>
> I dunno, so do you have any thoughts?
Here's a radical idea: Keep the two MSVC projects, but use only one file
list. How? Simple -- don't use MSVC to generate the project files.
Or rather, generate the project files once, then split out the file list
into a separate file. Maintain that by hand, and splice the pieces
together using a script. The result can even be updated automatically by
a checkin script. Oh, and forget the makefiles MSVC will write for you;
they're mainly a pain.
I know this means editing MSVC-generated files, but I've found this much
easier to do than trying to maintain non-trivial projects through the
GUI. The only caveat is that the generated .dsp's must have DOS-like
"\r\n" line endings.
I can have a go at that -- next year :-) -- if other people agree.
Oh, another thing: the public symbols should be exported either via the
.def file or with APR_DECLARE wrappers. Mixing the two is confusing, IMHO.
--
Brane Čibej
home: <br...@xbc.nu> http://www.xbc.nu/brane/
work: <br...@hermes.si> http://www.hermes-softlab.com/
ACM: <br...@acm.org> http://www.acm.org/
RE: cvs commit: apr apr.dsp apr.mak
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
> From: Branko Čibej [mailto:brane@xbc.nu]
> Sent: Thursday, December 28, 2000 10:47 AM
>
> William A. Rowe, Jr. wrote:
>
> > Whoa...
> >
> >> brane 00/12/21 15:02:36
> >>
> >> Modified: . apr.dsp apr.mak
> >> Log:
> >> Don't export symbols from static library.
> >
> >
> > Please watch out, you broke the build.
>
> Oops, my aplologies. "I just naturally assumed ..." Will be
> more careful next time.
Not a problem ... this just happened to occur as we were about
to roll a beta :-)
The issue remains :-/ There were three ideas all along of how
to do this; have two MSVC projects, apr and libapr that list all
the modules (and have to change in sync), one project with both
models (and this leads to a nightmare when that workspace
includes static + dynamic linkage to the library, as Apache
does), and finally, fly the second project from the first, perhaps
even use a script to rewrite the second with all the modules
contained in the first for building.
I dunno, so do you have any thoughts?
Re: cvs commit: apr apr.dsp apr.mak
Posted by Branko Čibej <br...@xbc.nu>.
William A. Rowe, Jr. wrote:
> Whoa...
>
>> brane 00/12/21 15:02:36
>>
>> Modified: . apr.dsp apr.mak
>> Log:
>> Don't export symbols from static library.
>
>
> Please watch out, you broke the build.
Oops, my aplologies. "I just naturally assumed ..." Will be more careful
next time.
--
Brane Čibej
home: <br...@xbc.nu> http://www.xbc.nu/brane/
work: <br...@hermes.si> http://www.hermes-softlab.com/
ACM: <br...@acm.org> http://www.acm.org/