+1 I'd like to know what had to be edited. There's always room for improvement, after all.
Ger PS for the ILM folks: the CreateDLL tool as it exists here has a bigger scope than OpenEXR (I thankfully grabbed your idea and took off ;-) ): it's used with such libraries as zlib, OpenSSL, hamsterdb, TRE, libxslt, and several in-house proprietary lib-turned-DLL's. Nevertheless, I hope the thing can be assimilated in its entirety; it's a generic tool and all items are used by OpenEXR, at least in its vcproj incantations here (which have 'global code optimization' turned on for most projects; that thing 'happens' in the MSVC _linker_ thus the need to feed that bastard a couple of extra commandline switches when you want things like that to happen in the definitive linker run (unless you wish to wonder why global code optimization doesn't bring a single ounce of performance when you select it in your MSVC projects: it happened, then CreateDLL made it unhappen before). This baby also picks up on inter-library-dependencies that MSVC dropped into the vanilla linker run when you have projects which depend on other projects=libraries, either static or dynamic ones. OpenEXR doesn't have third-party dependencies, but derived work does. Side-effect is that you now 'always' get to automagically pick the right MSVC RunTime library, static or dynamic, debug or non-debug, etc. as that datum is lifted from the map files. Allows for easy copy&paste between postbuild target edit fields for various platforms and projects in MS Dev Studio. It's a self-serving request as it saves me quite some tracking hassle in the future and this way CreateDLL can be a very viable alternative for those porting any UNIX libs/.so's to Windows without the need to hand-maintain .DEF files and/or sprinkle the code with magic dllimport/export pragma dust (which is your only way when you do C++ templates (or many classes) in a DLL setting). The 'pragma way' was our old method for providing 'multiplatform portable code' over here for years, but 'twas a real maintenance hellhound when you like to 'track' third-party libs on a [somewhat] regular basis. Bits of this was mentioned somewhere in early 2009 and then it got bloody silent on my part when it came to delivering production-tested code at the end. :-( Needed the kick in the a.*, apparently. On Thu, Mar 11, 2010 at 6:20 PM, Piotr Stanczyk <pstanc...@ilm.com> wrote: > Good news. Could you mail out the changes you had to make - thanks. > > Piotr > > Stephan Menzel wrote: > >> Ger, >> >> Works. Like. A. Charm. >> >> Finally I can link ImageMagick. >> Thank you so very much! You've saved me from despair in face of what >> Microsoft considers a developer platform. Great stuff. >> I strongly encourage ILM to take in these changes. I could provide the >> whole package with Ger's changes incorporated if you are interested. >> Actually, you did something not very different from what I started, >> but so much further and better. I almost only had to drop it in. You >> were right with your 95% estimation. I had to change very little. >> >> Cheers, >> >> Stephan >> >> On Thu, Mar 11, 2010 at 11:00 AM, Ger Hobbelt <g...@hobbelt.com> wrote: >> >> >>> Yes, I did, and, no, they were not. It's just me veering off and paying >>> attention to other things. For a proper move upstream the changes should >>> be >>> more clearly documented as others are using this material in their >>> production evironments too and not everybody likes a 'hey, what the heck, >>> let's upgrade!' without some pretty detailed prior notion of what they're >>> getting themselves in to. ;-) >>> >>> Anyway, attached two 7zip archives: one is the CreateDLL sources (pull a >>> [visual] diff to see what I did, don't get flabberghasted by the code >>> changes, just follow the comments and you should do fine; the changelog >>> is >>> at the top of createDLL.cpp and should proceed where the public ILM >>> version >>> stops); the other is just an example vcproj (Half.vcproj) to show what >>> may/may not have to change for you to make it work (passing the right >>> args >>> to CreateDLL in the postbuild process). >>> >>> >>> Why do I call that Hlf.vcproj one a *sample*? >>> Because we have very strict project organization rules around here, where >>> every solution MUST dump all build binaries in the >>> <_solution_dir>/bin/Debug|ReleaseXYZ directory, where XYZ is a combo of >>> target CPU and platform. This means that the OpenEXR vcproj files all >>> were >>> edited to not only deliver in the original spot but also in this >>> directory >>> so that our package and test scripts can handle it all (one structure for >>> everything means less FUBAR before deadlines and less maintenance on >>> stuff >>> like install scripts, which you'd rather not edit, ever. ;-) >>> >>> Just open the vcproj with notepad++ or similar text editor, it's XML >>> anyway, >>> and have a look-see when you compare with your own half.vcproj. The >>> different destination directory stuff should pop out pretty quickly. The >>> batchfiles have been edited for this purpose as well, but I didn't >>> include >>> them; just copying files to different destinations, is all. >>> >>> IlmBase-src.7z is the CreateDLL source code + adjusted vcproj. Code >>> should >>> be drop-in (95% success chance is my guess); take care **NOT** to just >>> drop-in the CreateDLL.vcproj due to the above-mentioned altered project >>> delivery structure. Pull a diff on that one and copy&paste what you know >>> will work and take it from there. >>> >>> The CreateDLL source has several comment chunks where I describe what I >>> found on our systems and what tricks I pulled to make the bugger do my >>> bidding to a tee. code organization wise it's the .MAP file parser that >>> got >>> an overhaul, plus added sprinkles to have CreateDLL pass along some >>> command >>> args to the underlying linker plus other tidbits which I forgot but >>> probably >>> use quite frequently over here. >>> >>> Can't guarantee within-24h response, but send me any issues and I'll try >>> to >>> resolve them asap. >>> >>> >>> On Thu, Mar 11, 2010 at 9:21 AM, Stephan Menzel < >>> stephan.men...@gmail.com> >>> wrote: >>> >>> >>>> Hi Ger, >>>> >>>> On Thu, Mar 11, 2010 at 12:00 AM, Ger Hobbelt <g...@hobbelt.com> wrote: >>>> >>>> >>>>> Anyway, this is off the top of my head. Just give the word and a >>>>> CreateDLL >>>>> source will be on its way. >>>>> >>>>> >>>> Wow, that would be very helpful indeed. Much appreciated. >>>> Did you ever consider bringing this into upstream or are the ILM guys >>>> hesitant about this? >>>> >>>> Cheers, >>>> >>>> Stephan >>>> >>>> >>> >>> -- >>> Met vriendelijke groeten / Best regards, >>> >>> Ger Hobbelt >>> >>> -------------------------------------------------- >>> web: http://www.hobbelt.com/ >>> http://www.hebbut.net/ >>> mail: g...@hobbelt.com >>> mobile: +31-6-11 120 978 >>> -------------------------------------------------- >>> >>> >>> >>> >> >> >> _______________________________________________ >> Openexr-devel mailing list >> Openexr-devel@nongnu.org >> http://lists.nongnu.org/mailman/listinfo/openexr-devel >> >> > > -- Met vriendelijke groeten / Best regards, Ger Hobbelt -------------------------------------------------- web: http://www.hobbelt.com/ http://www.hebbut.net/ mail: g...@hobbelt.com mobile: +31-6-11 120 978 --------------------------------------------------
_______________________________________________ Openexr-devel mailing list Openexr-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/openexr-devel
