On 10/18/2017 7:41 PM, William A Rowe Jr wrote:
Two additional footnotes...
On Wed, Oct 18, 2017 at 4:13 PM, Gregg Smith <g...@gknw.net> wrote:
On 10/18/2017 7:58 AM, William A Rowe Jr wrote:
Please cast your votes on the following candidate packages;
I'm not there to vote yet, my question is how did you expect us to build APU
with a precompiled lib and this lib put where?
That was addressed in my first response...\
No, you told me to see CHANGES and makefile.win. If you had really read
what I said you would have realized I already did, at least makefile.win
which didn't give me any clues, nor did CHANGES.
*) Win32: Introduce XML_PARSER build-time variable to select the expat
library name to be linked to libaprutil-1.dll. See Makefile.win
*) Win32: Removed lingering xml/xml.dsp project forked from the expat
Project in the 1.9x era. Use expat's maintained build schema instead,
prior to building apr-util.
It's big info is look at makafile.win which I did, and stated such from
the beginning, see the first quoted line below
.
Looking at both makafile.win and libaprutil.mak I see not much for pointers
here. I see an include of ./xml/expat/lib in libaprutil.mak so do I really
have to put expat in the xml folder? Seem it should be outside the apr-util
folder so the include would be like /I ../expat/lib
I am 100% in agreement that moving forwards, we suggest a path of
../expat/ vs expecting anyone to embed some other project's sources
deep within ./xml/expat - that seems absurd. OTOH for those doing
so, I don't think we need to break them...
You should have done this now. You've already upset the flow so just
take it all the way. This is why I was against this in the first place
and said this should not be done till 1.7, regardless of said "promise,"
we should just say opps, sorry and move forward with 1.7 where we will
promise again yet have something in svn showing just that so it's not
another hollow promise.
Further, no /libpath: pointing to where libexpat.lib is grabbed from at
apu's linking. I don't remember vc ever being that smart to just find it, it
knew it was in ./xml/libR because that's where it put xml.lib, which we
don't have anymore.
Adding doubled /I /LIBPATH "default" options isn't silly, it's actually a
good idea... with that said...
As I said, there is "no /LIBPATH present" so how is it even doubled? VC
cannot find the lib. So what your saying here is silly.
cmake -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=Release -DBUILD_shared=OFF
gives me an expat.lib, not libexpat.lib, so unless I'm missing something
really obvious that's right under my nose, I don't get it :)
As I pointed out in the prior email, there is resolution logic already within
the cmake model. If there are bugs, we should send those upstream.
There's no bug that I know of upstream.
My own build model is one component at a time, never changing the LIB
or INCLUDE path, but just layering one by one by one. Pretty much like
every *nix environment out there. At minimum, cmake can resolve this if
the LIB and INCLUDE path point to this target.
This ain't Unix and I'm tired of that rationale.
When we first started debating, we hotly contested whether an expat
xml.dsp project belonged in the apr-util tree, after APR PMC voted to
expel this component from our own maintenance. I understood the pain
of extracting this and have always invited dialog and participation about
the resolution of this unsustainable situation.
If you have more and better ideas to offer, that DON'T involve this
project substituting its logic for the expat project's logic, please bring
them here, I'm all ears.
I did in the beginning, leave as is and do whatever your heart desires
in 1.7. Even go as far and ask the others to put there attention to 1.7
instead of 1.6.
I told you off-list I wasn't going to have a veto war with you but this
is rediculous and I am really tempted to back out on that and veto this
mess.
Other things of note. XML_PARSER=libxml doesn't get to libaprutil.mak, I
get an error about ".lib," meaning it didn't get passed (even though it
does with $(XMLOPTS), VC just doesn't do it. I believe this is the
reason I just sent a flag from .win to the .mak files and repeated the
THIS=that in the .maks for OpenSSL 1.1.0.
Now, seeing Steffen's problems and what Michal had to go through to get
this to build for him, so I'm -1 with apu 1.6.1.
If you want to continue down this road then I ask you to create a
readme.win file explaining what us stupid people need to do, how you
expect us to build expat (so someone doesn't foolishly think they can
build it with cmake as I did) and where to place it before we start the
apu build, fix the makefiles and as Steffen suggested, do something with
cvtdsp.pl to handle the change to the .dsps (too bad cvtdsp's in apr).
I didn't pay much attention to apr or apr-iconv but since both get built
before apu IIRC I'll have a look and vote on those.
