> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
Bo> On 6/12/06, Jean-Marc Lasgouttes <[EMAIL PROTECTED]> wrote:
>> > "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>>
Angus> At least, I understand that Jean-Marc passes some magic to the
Angus> gettext code to tell it where to find these .mo fi
On 6/12/06, Jean-Marc Lasgouttes <[EMAIL PROTECTED]> wrote:
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
Angus> At least, I understand that Jean-Marc passes some magic to the
Angus> gettext code to tell it where to find these .mo files...
>> The names of the mo files is PACKAGE.mo. So it a
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
Angus> At least, I understand that Jean-Marc passes some magic to the
Angus> gettext code to tell it where to find these .mo files...
>> The names of the mo files is PACKAGE.mo. So it all depends on how
>> the PACKAGE variable is modified when usi
Angus> At least, I understand that Jean-Marc passes some magic to the
Angus> gettext code to tell it where to find these .mo files...
The names of the mo files is PACKAGE.mo. So it all depends on how the
PACKAGE variable is modified when using version-suffix.
This is true under *nix, but for wi
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>> If this hasn't changed recently, with autotools the locales also
>> have the version suffix on windows. That's not the case for scons.
>> I actually prefer this last behaviour.
Angus
Peter Kümmel wrote:
> Bo Peng wrote:
>>> This patch solves it for me.
>> Thanks, Abdel. I do not really know what is going on there, but it
>> works on linux as well so I submitted it.
>>
>> Joost, please check if you still have any build or version_suffix problem.
>>
>> Bo
>>
>>
>
> I don't fully
Bo Peng wrote:
>> This patch solves it for me.
>
> Thanks, Abdel. I do not really know what is going on there, but it
> works on linux as well so I submitted it.
>
> Joost, please check if you still have any build or version_suffix problem.
>
> Bo
>
>
I don't fully understand all the m4 and s
This patch solves it for me.
Thanks, Abdel. I do not really know what is going on there, but it
works on linux as well so I submitted it.
Joost, please check if you still have any build or version_suffix problem.
Bo
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Bo Peng wrote:
D:\devel\lyx\trunk\intl\dcigettext.c:933: error: `ICONV_CONST'
undeclared (first use in this function)
This is the problem I try to solve. Now, do you have ICONV_CONST in
your src/config.h?
No:
/* #undef ICONV_CONST */
If no
Abdelrazak Younes wrote:
Bo Peng wrote:
D:\devel\lyx\trunk\intl\dcigettext.c:933: error: `ICONV_CONST'
undeclared (first use in this function)
This is the problem I try to solve. Now, do you have ICONV_CONST in
your src/config.h?
No:
/* #undef ICONV_CONST */
If not, please paste here the p
Bo Peng wrote:
D:\devel\lyx\trunk\intl\dcigettext.c:933: error: `ICONV_CONST'
undeclared (first use in this function)
This is the problem I try to solve. Now, do you have ICONV_CONST in
your src/config.h?
No:
/* #undef ICONV_CONST */
If not, please paste here the portion of config.log
that
D:\devel\lyx\trunk\intl\dcigettext.c:933: error: `ICONV_CONST'
undeclared (first use in this function)
This is the problem I try to solve. Now, do you have ICONV_CONST in
your src/config.h? If not, please paste here the portion of config.log
that look like this:
scons: Configure: Check if the
Bo Peng wrote:
The fix is in. Please test.
I have this:
gcc -o release\intl\dcigettext.o -c -O3 -w
-DLOCALEDIR=\"d:/program/lyx-svn\\Resources/locale\" -DLOCALE_ALIAS_
PATH=\"d:/program/lyx-svn\\Resources/locale\" -DLIBDIR=\"../../lib\"
-DIN_LIBINTL -DENABLE_RELOCATABLE=1 -DIN_LIBRARY
-DINS
Bo Peng <[EMAIL PROTECTED]> writes:
> > C:\Documents and Settings\Bo\Application Data\LyX-15x\
> > It's only this last directory that needs to be suffixed on Windows.
> That means only config.h needs that PACKAGE macro (go to package.C),
> and install does not need any VERSION_SUFFIX. I see.
On
The fix is in. Please test.
Bo
C:\Program Files\LyX\bin\lyx.exe
C:\Program Files\LyX\Resources\locale\en\lyx.mo
C:\Program Files\LyX\Resources\lyxrc.dist
C:\Documents and Settings\Bo\Application Data\LyX-15x\
It's only this last directory that needs to be suffixed on Windows.
That means only config.h needs that PACKAGE macr
> 1. version_suffix=yes now works as expected
This semantic is different from that of the autotools and less flexible.
I had version_suffix=xxx before, now I am adding version_suffix=yes.
Windows will find them if they're in the PATH...
Perhaps Joost's installer should offer to install them,
Bo Peng <[EMAIL PROTECTED]> writes:
> A patch has just been submitted to fix version_suffix under *nix.
> Briefly,
> 1. version_suffix=yes now works as expected
This semantic is different from that of the autotools and less flexible. The
autotools version is either
configure --with-version-su
Bo Peng <[EMAIL PROTECTED]> writes:
> > No, I did a full recompile. On Windows, the directory names should not
> > contain a version suffix except the users directory.
> Which ones? We have:
> program files/lyxSUFFIX
This one doesn't need a suffix. The package is fully self-contained.
> bin/lyxSU
On 6/9/06, Joost Verburg <[EMAIL PROTECTED]> wrote:
Bo Peng wrote:
> 2. change of this option will ensure a full recompile. (I suspect
> that Joost's problem is with fast_start, which bypass src/config.h).
No, I did a full recompile. On Windows, the directory names should not
contain a version
Bo Peng wrote:
2. change of this option will ensure a full recompile. (I suspect
that Joost's problem is with fast_start, which bypass src/config.h).
No, I did a full recompile. On Windows, the directory names should not
contain a version suffix except the users directory.
Joost
Dear all,
A patch has just been submitted to fix version_suffix under *nix.
Briefly,
1. version_suffix=yes now works as expected
2. change of this option will ensure a full recompile. (I suspect
that Joost's problem is with fast_start, which bypass src/config.h).
3. lyx.1 etc are installed as
> It doesn't define how the individual .mo files are called.
The PACKAGE macro does.
JMarc
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> I get your point but I am almost sure that they both work! I guess
> package.C tells lyx how the locales are named.
Package.C defines
std::string localedir();
It doesn't define how the individual .mo files are called.
Angus
Angus Leeming wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
If this hasn't changed recently, with autotools the locales also have
the version suffix on windows. That's not the case for scons. I actually
prefer this last behaviour.
Then presumably building lyx with --with-version-suffix
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> If this hasn't changed recently, with autotools the locales also have
> the version suffix on windows. That's not the case for scons. I actually
> prefer this last behaviour.
Then presumably building lyx with --with-version-suffix using scons will
Angus Leeming wrote:
Bo Peng <[EMAIL PROTECTED]> writes:
On 6/9/06, Joost Verburg <[EMAIL PROTECTED]> wrote:
The version-suffix option of the scons build system doesn't seem to work
properly. Some resources are installed in a directory with a wrong name
and the suffix is not added to the users
Bo Peng <[EMAIL PROTECTED]> writes:
> On 6/9/06, Joost Verburg <[EMAIL PROTECTED]> wrote:
> > The version-suffix option of the scons build system doesn't seem to work
> > properly. Some resources are installed in a directory with a wrong name
> > and the suffix is not added to the users directory.
On 6/9/06, Joost Verburg <[EMAIL PROTECTED]> wrote:
The version-suffix option of the scons build system doesn't seem to work
properly. Some resources are installed in a directory with a wrong name
and the suffix is not added to the users directory.
Could you elaborate on what command you use, w
The version-suffix option of the scons build system doesn't seem to work
properly. Some resources are installed in a directory with a wrong name
and the suffix is not added to the users directory.
Joost
30 matches
Mail list logo
