> > One more thing I realised - we need two different types of
> versioninfo
> > structures, because one fields tells wether it's a DLL or
> an app. How
> > would you prefer this done - either using
> > $(WIN32VERDLL)/$(WIN32VERAPP) (or
> $(PORTOBJSHLIB)/$(PORTOBJAPP) if we
> > go down that route), or by setting another field along
> FILEDESC called FILETYPE or similar?
> >
>
> I think I would go with PORTOBJ + FILEDESC + FILETYPE for
> now. ISTM that gets it clean enough, and it can be revisited
> later if necessary.
>
> One thing that I think Peter referred to - libraries that we
> version (e.g.
> libpq) in standard Unix major.minor style should probably
> carry that version rather than the PostgreSQL version number.
Aggh, I knew there was one more issue that needed resolving before I
could move on :)
This we can do, but it does two things:
1) We'll have to add extra code somewhere to have it pick
SO_MAJOR_VERSION,SO_MINOR_VERSION in the cases where it is a shared
library, and PG_VERSION_NUMERIC when it's an app. But this can probably
be done in the rule in Makefile.global.
2) We'll *have* to start actually bumping at least minor versions
whenever we change the code in a sharaed lib. Which we don't do now,
except for libpq. For example, plperl still says 0.0, and plpgsql says
1.0. Also, all the conversion procs are at 0.0, and they all build from
the same rule. That means they all need to get bumped when one of them
changes. That may be a good idea for unix platforms as well, but it is
more work during releases that has to be included. Not sure if we want
to buy into that?
Oh, and for the record, we version libpq.dll on windows in the 7.x.y
manner, and have been doing so ever since we first added win32 support.
We can't really back that one down, so we'd need an exception for that
one.
//Magnus