Re: [Crystaldoc-main] Splitting crystaldoc in lang and build packages

[Vincent K. <vi...@ie...>]

Le jeu 18/12/2003 =E0 20:28, Arthur Huillet a =E9crit :
> > if it's possible, okay
> > at least for now building our 0.96 french manual using 0.97
> > original files when translated one doesnt exists seem to produce
> > good output (don't have checked precisely); at least no no-go error
> >=20
> > So there's hope to achieve this :-)
> > We should check if build process changed by diffing CS involved
> > makefiles
> /jamfiles
> >=20
>=20
> the final building process should not be linked to CS in any way !

i was speaking of making our own makefiles based on CS one, and check
which changes occured beetween CS 0.96 and CS 0.97 to make sure our
makefiles can cope with these two different CS versions.

And i see at least one good reason we need a "link" with CS,
it's simply for including english texinfo file when we don't provide a
translated one. Probably through the use of $CRYSTAL.

There are 2 or 3 solutions if you really don't want to rely on CS:
- producing a partial manual (ie. just the translated chapters)
- import all english file (& pictures), then translate them
- check out CS files from CVS (the CVS version or the 0.96.4) when
  building manual (automatically on our CVS) then delete them ?

> > can you describe us how the retrieving and updating would differ ?
>=20
>=20
> if we consider using different modules for ES and FR [and also for sure=
=20
> base coz that's much easier to maintain] the cvs would be structured as=
=20
> follow :
>=20
> CVSROOT/* :
>=20
> CVSROOT/fr : fr module
> CVSROOT/es : es module
> CVSROOT/base : base module
>=20
> ie when you, the developer (documentation maintainer), have a=20
> modification to do to the base :
>=20
> cvs co base
> [modifications]
> cvs commit
>=20
> or when we will be translating doc :
>=20
> cvs [co/update] fr
> cvs commit
>=20
>  > can a module (ie the base) be automatically retrieved when getting
>  > one of the languages modules ?
>  > if so, i buy ;-)
>=20
> we can but we don't f****** care about it !!

mmm

> the building process is a different work than translation, then i see n=
o=20
> reason for wich we shouldn't make another module :)
>=20
> if you're thinking as an enduser then what's possible for CVS is that :
>=20
> cvs co base
> cd base
> cvs co fr
>=20
> (note it would depend on our building process)

that's the whole point, we can therefore not rely on relatives paths

> > Wouldn't module splitting require having two (or 3 with 2 languages)
> > base directories for each (on local side) ?
>=20
> that's even the definition of a cvs module :)
>=20
>=20
> I hope we will be able to find a solution for this building process.
>=20
> To my mind we need cvs modules. Or we're gonna die under an horrible=20
> garbage 3 days after having committed our changes :)

where would the garbage come from ? do you mean from potential mistake
or what ?