"Dimitrie O. Paun" dimi@intelliware.ca writes:
There is no reason to have our own db2html hack. It creates problems, we never got it to work reliably on different distros, etc. We should use the one provided with the system, it's a far safer bet. Also, our build system uses the standard db2html, it's only the make_winehq script that used it. And that script is used only on WineHQ, where we should be able to control the environment to have a half-decent db2html that supports the -d option.
Do we actually need that make_winehq script at all? It seems almost everything it does is already done in the normal makefiles, except the bit about the winehq stylesheet. And I'm not sure what this one is for, since the docs on WineHQ look identical to the one we get by doing 'make doc'. Does anyone know how this is all supposed to work?
On 19 Apr 2003, Alexandre Julliard wrote:
Do we actually need that make_winehq script at all? It seems almost everything it does is already done in the normal makefiles, except the bit about the winehq stylesheet. And I'm not sure what this one is for, since the docs on WineHQ look identical to the one we get by doing 'make doc'. Does anyone know how this is all supposed to work?
Yes, you are right, and my plan is to eventually remove make_winehq altogether, but I'm taking it one step at a time. If you want me to go directly for the big jump, just let me know. :)
"Dimitrie O. Paun" dimi@intelliware.ca writes:
Yes, you are right, and my plan is to eventually remove make_winehq altogether, but I'm taking it one step at a time. If you want me to go directly for the big jump, just let me know. :)
Either way is OK with me, but the big jump would certainly have the advantage to make it clear where we are going. Right now I'm not sure I understand how this stuff is working on the WineHQ side, and what would break if we change things in the source tree.
On 19 Apr 2003, Alexandre Julliard wrote:
Either way is OK with me, but the big jump would certainly have the advantage to make it clear where we are going. Right now I'm not sure I understand how this stuff is working on the WineHQ side, and what would break if we change things in the source tree.
I tried to break the jump into small, incremental changes. This one is completly transparent -- it should not affect anything on WineHQ.
My next steps: -- get rid of the .shtml stuff, we should just serve the regular .html documents we produce. This should get rid of winehq.dsl -- enhance the Makefile to the point where it can do most/all(?) that make_winehq does. This should be a no-op from WineHQ POV -- Jer checks it out, and when happy we can simply delete the make_winehq script
The big change is that before you could run make_winehq without having to configure the wine tree. If we move stuff to the Makefile, you will not be able to do so. BTW, is there a way to check out only documentation and configure? Will such a thing work: cvs co wine/documentation cd wine cvs up configure ./configure cd documentation make html Hmm, I'll have to check it out. But we need to do that anyway IMO because we should export the man pages as HTML docu on the site as well, and some of them are actually man.in pages that need to go through the Makefiles to become .man pages.
It makes it so much easier for me to go to next step after you have applied the patch, thus my slow pace.
"Dimitrie O. Paun" dimi@intelliware.ca writes:
The big change is that before you could run make_winehq without having to configure the wine tree. If we move stuff to the Makefile, you will not be able to do so. BTW, is there a way to check out only documentation and configure? Will such a thing work: cvs co wine/documentation cd wine cvs up configure ./configure cd documentation make html Hmm, I'll have to check it out. But we need to do that anyway IMO because we should export the man pages as HTML docu on the site as well, and some of them are actually man.in pages that need to go through the Makefiles to become .man pages.
Actually the release script already takes care of all that, so unless we want to update the doc between releases that shouldn't be an issue. In fact I'm not sure why we build the doc on winehq at all, we could simply use the doc packages that I put on ibiblio.
It makes it so much easier for me to go to next step after you have applied the patch, thus my slow pace.
Sure, I'll apply it, thanks for the explanations.
On Sat, 2003-04-19 at 20:45, Alexandre Julliard wrote:
Actually the release script already takes care of all that, so unless we want to update the doc between releases that shouldn't be an issue. In fact I'm not sure why we build the doc on winehq at all, we could simply use the doc packages that I put on ibiblio.
All, I'll need to to is update the wine_release script that runs when a new release is made. This script simply builds the docs, then untars the shtml version to the correct location. If we drop the shtml version thats fine as well.
Also, not building the docs would be a good thing, a simple wget of the tgz file, like Alexandre suggested is cool with me as well.
On 20 Apr 2003, Jeremy Newman wrote:
All, I'll need to to is update the wine_release script that runs when a new release is made. This script simply builds the docs, then untars the shtml version to the correct location. If we drop the shtml version thats fine as well.
So if we're all in agreement, let's just do this -- there's no point in beating around the bush. All we need now is to: cvs rm -f documentation/{make_winehq,winehq.dsl}
And to do the wget in wine_release. BTW, it would be nice to have this script in CVS as well, either in wine/tools or in tools/ so that patches can be submitted, or to simply help people understand the process better.
I'll send in a patch for WineHQ to remove the shtml references.
-
Alexandre Julliard -
Dimitrie O. Paun -
Jeremy Newman