Re: Release stamping (Was: [CORE] Schedule for release?)

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: Release stamping (Was: [CORE] Schedule for release?)
Дата
Msg-id 6BCB9D8A16AC4241919521715F4D8BCEA35832@algol.sollentuna.se
обсуждение исходный текст
Ответ на Re: Release stamping (Was: [CORE] Schedule for release?)  ("Dave Page" <dpage@vale-housing.co.uk>)
Ответы Re: Release stamping (Was: [CORE] Schedule for release?)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> > Getting late into this discussion, so I may be completely
> off here :-)
> > How's that going to work+ pg_config.h.win32 needs to know
> > win32 platform
> > specifics, right? So it has to be created, in that case, on
> win32. But
> > when you're building with MSVC, you don't run configure, because
> > windows can't run that (without the mingw layer).
>
> Sorry - we're just talking about getting the version number
> in there automatically to avoid it getting forgotten during
> release bundling.

I can see that being a good idea. But I don't see Toms ./configure
solution working.

What we could do is have the msvc build scripts edit the file and
replace the version with something it reads from configure.in when run.
This would require that we zap the old "win32.mak" method of buildnig
win32 stuff, which we can't do just yet but IMHO can eventually do.

The other option is, I would think, to break out the version #defines
into a separate headerfile that's used on all platforms, and use that
one *instead* of configure to set it.

//Magnus


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Dave Page"
Дата:
Сообщение: Re: Release stamping (Was: [CORE] Schedule for release?)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Release stamping (Was: [CORE] Schedule for release?)