> > All that is then needed is to teach each binary to link in
> "win32ver.o".
> > For initdb, I've done this like:
> > ifeq ($(PORTNAME), win32)
> > FILEDESC=initdb - initialize a new database cluster
> > OBJS+=win32ver.o
> > endif
>
> > I assume what you would like is to have just the FILEDESC
> row in there?
>
> That would be ideal, but this is probably close enough if no
> one has a great idea about how to get rid of the manual
> addition to $(OBJS).
Ok. Since nobody has added anything, I assume there is nobody around
with an idea on how to do that. :-(
> > One way would be to just add something like $(PORTOBJ) and have
> > Makefile.global add whatever special .o files are required for the
> > current port. That way we wouldn't teach it specifically about the
> > win32 version stuff, but we'd still have to teach it to
> look somewhere...
>
> Yeah, that's not a bad idea. If anyone can think of
> plausible reasons why we might end up with other things
> needing to be built for every executable, it would be quite
> reasonable to go this route.
Again, since nobody said anything, I assume nobody had an idea there.
The question then - would you prefer me to add $(WIN32VER) to specify
what it is, or should I go with $(PORTOBJ) anyway, in case we find
something in the future?
> I was originally thinking of somehow migrating the executable
> build rules into a single pattern rule, but given the lack of
> any suffix on executable names it's not clear how to use a
> pattern rule for the purpose. And the existing rules are
> diverse enough that it might be a real pain to construct such
> a pattern rule anyway.
Yeah, that's what I figured.
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?
//Magnus
