openexr-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Openexr-devel] CreateDLL eliminates C style wrapper functions


From: Ger Hobbelt
Subject: Re: [Openexr-devel] CreateDLL eliminates C style wrapper functions
Date: Thu, 11 Mar 2010 19:46:13 +0100

+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 <address@hidden> 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 <address@hidden> 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 <address@hidden>
wrote:
   
Hi Ger,

On Thu, Mar 11, 2010 at 12:00 AM, Ger Hobbelt <address@hidden> 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:   address@hidden
mobile: +31-6-11 120 978
--------------------------------------------------


   


_______________________________________________
Openexr-devel mailing list
address@hidden
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:   address@hidden
mobile: +31-6-11 120 978
--------------------------------------------------


reply via email to

[Prev in Thread] Current Thread [Next in Thread]