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... > 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... > 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... > 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. 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. 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.
