Re: Re: [LyX features/empty-length] Latest changes from Uwe for tex2lyx and lyx2lyx
Am Dienstag, 28. Mai 2013 um 13:42:33, schrieb Jean-Marc Lasgouttes > 27/05/2013 22:18, Vincent van Ravesteijn: > > I tested the branch a bit more. > > > > - When you just implemented this, my LyX was translated immediately, but > > now it can't find the translations anymore. This is a pity. > > > > I don't really understand the following: > > > > + if (in_build_dir_) > > +return FileName(top_srcdir().absFileName() + "/po/" > > ++ c + ".gmo"); > > > > So, if we run in the build dir, we look for the gmo files in the source > > dir ? Shouldn't we be looking the build dir then ? What about the > > attached ? > > Traditionally, autotools put the .gmo files in the source directory. The > reason is that these files are distributed in the tar.gz file, so that > users do not need gettext to compile LyX. > > It seems that cmake does not follow this rule. Does this mean that .gmo > files are not distributed? They are created in the build-directory. And not distributed yet. > I would be OK with either having cmake generate gmo file in source or > have special code in Package.cpp to catter for different build systems. > ... > JMarc Kornel signature.asc Description: This is a digitally signed message part.
Re: [LyX features/empty-length] Latest changes from Uwe for tex2lyx and lyx2lyx
27/05/2013 22:18, Vincent van Ravesteijn:
I tested the branch a bit more.
- When you just implemented this, my LyX was translated immediately, but
now it can't find the translations anymore. This is a pity.
I don't really understand the following:
+ if (in_build_dir_)
+return FileName(top_srcdir().absFileName() + "/po/"
++ c + ".gmo");
So, if we run in the build dir, we look for the gmo files in the source
dir ? Shouldn't we be looking the build dir then ? What about the
attached ?
Traditionally, autotools put the .gmo files in the source directory. The
reason is that these files are distributed in the tar.gz file, so that
users do not need gettext to compile LyX.
It seems that cmake does not follow this rule. Does this mean that .gmo
files are not distributed?
I would be OK with either having cmake generate gmo file in source or
have special code in Package.cpp to catter for different build systems.
- I get an error that the language C could not be found. I know this is
logical when the po-files can't be found, but it is a bit confusing that
the language is "C".
This is related to this code snippet in the current code:
// Find the code we have for a given language code. Return empty if not
found.
string realCode(string const & c)
{
// Qt tries to outsmart us and transforms en_US to C.
string code = (c == "C") ? "en" : c;
Instead of doing that in the realCode() function, we could just change
the setting of the lang_ member.
JMarc
Re: [LyX features/empty-length] Latest changes from Uwe for tex2lyx and lyx2lyx
Op 27-5-2013 18:05, Jean-Marc Lasgouttes schreef:
24/05/2013 15:07, Vincent van Ravesteijn:
By the way, this doesn't always work. The kill-gettext branch, for
instance, has master merged in a few times to fix merge conflicts. Now,
rebasing onto the merge-base does do no good.
Vincent, I want to merge this kill-gettext branch now. Is there
something I should do to make it less ugly? I do not understand why it
requires such ugly merges in the middle. What about good old hand-made
conflict resolution?
Anyway, if you tell me to merge it as it is, it will be fine with me.
JMarc
I tested the branch a bit more.
- When you just implemented this, my LyX was translated immediately, but
now it can't find the translations anymore. This is a pity.
I don't really understand the following:
+ if (in_build_dir_)
+return FileName(top_srcdir().absFileName() + "/po/"
++ c + ".gmo");
So, if we run in the build dir, we look for the gmo files in the source
dir ? Shouldn't we be looking the build dir then ? What about the attached ?
- I get an error that the language C could not be found. I know this is
logical when the po-files can't be found, but it is a bit confusing that
the language is "C".
Vincent
>From 412f013cdd7f1c70e631022d5ab4489ce60c216b Mon Sep 17 00:00:00 2001
From: Vincent van Ravesteijn
Date: Mon, 27 May 2013 21:43:50 +0200
Subject: [PATCH] Look for locale dir in the build directory
---
src/support/Package.cpp | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/src/support/Package.cpp b/src/support/Package.cpp
index 24cf8ca..725999a 100644
--- a/src/support/Package.cpp
+++ b/src/support/Package.cpp
@@ -83,7 +83,8 @@ FileName findLyxBinary(FileName const & abs_binary);
FileName const get_document_dir(FileName const & home_dir);
-FileName const get_locale_dir(FileName const & system_support_dir);
+FileName const get_locale_dir(FileName const & system_support_dir,
+ FileName const & build_support_dir);
FileName const get_system_support_dir(FileName const & abs_binary,
string const &
command_line_system_support_dir);
@@ -130,7 +131,7 @@ Package::Package(string const & command_line_arg0,
// Find the LyX executable
lyx_binary_ = findLyxBinary(abs_binary);
- locale_dir_ = get_locale_dir(system_support_dir_);
+ locale_dir_ = get_locale_dir(system_support_dir_, build_support_dir_);
FileName const default_user_support_dir =
get_default_user_support_dir(get_home_dir());
@@ -168,8 +169,7 @@ void Package::set_temp_dir(FileName const & temp_dir) const
FileName Package::messages_file(string const & c) const
{
if (in_build_dir_)
- return FileName(top_srcdir().absFileName() + "/po/"
- + c + ".gmo");
+ return FileName(locale_dir_.absFileName() + "/" + c + ".gmo");
else
return FileName(locale_dir_.absFileName() + "/" + c
+ "/LC_MESSAGES/" PACKAGE ".mo");
@@ -408,7 +408,8 @@ FileName const get_document_dir(FileName const & home_dir)
// Several sources are probed to ascertain the locale directory.
// The only requirement is that the result is indeed a directory.
-FileName const get_locale_dir(FileName const & system_support_dir)
+FileName const get_locale_dir(FileName const & system_support_dir,
+ FileName const & build_support_dir)
{
// 1. Use the "LYX_LOCALEDIR" environment variable.
FileName const path_env = extract_env_var_dir("LYX_LOCALEDIR");
@@ -424,7 +425,12 @@ FileName const get_locale_dir(FileName const &
system_support_dir)
if (path.exists() && path.isDirectory())
return path;
- // 3. Fall back to the hard-coded LOCALEDIR.
+ // 3. Search for build_support_dir/../po
+ path = FileName(addPath(build_support_dir.absFileName(), "../po"));
+ if (path.exists() && path.isDirectory())
+ return path;
+
+ // 4. Fall back to the hard-coded LOCALEDIR.
path = hardcoded_localedir();
if (path.exists() && path.isDirectory())
return path;
--
1.8.0.msysgit.0
Re: Re: [LyX features/empty-length] Latest changes from Uwe for tex2lyx and lyx2lyx
Am Montag, 27. Mai 2013 um 19:59:44, schrieb Vincent van Ravesteijn > Op 27-5-2013 18:05, Jean-Marc Lasgouttes schreef: > > 24/05/2013 15:07, Vincent van Ravesteijn: > >> By the way, this doesn't always work. The kill-gettext branch, for > >> instance, has master merged in a few times to fix merge conflicts. Now, > >> rebasing onto the merge-base does do no good. > > > > Vincent, I want to merge this kill-gettext branch now. Is there > > something I should do to make it less ugly? I do not understand why it > > requires such ugly merges in the middle. What about good old hand-made > > conflict resolution? > > > > Anyway, if you tell me to merge it as it is, it will be fine with me. > > > > JMarc > > It's not that ugly. It was required to immediately fix the merge > conflicts at the moment they arise. > > First, if you would do it at the end, it would be more difficult and you > might forget some conflicts. For example, you probably would forget the > added 'intl' dependency of check_layout. > > Second, other people that would like to try out the feature could not > merge it directly in their master because of the merge conflicts. So, we > can offer them a branch that can be merged into master. > > Anyway, I rebased the branch onto master now. Shall I push it later ? > > Vincent I vote for merging it with the master now, and get rid of this branch. Kornel signature.asc Description: This is a digitally signed message part.
Re: [LyX features/empty-length] Latest changes from Uwe for tex2lyx and lyx2lyx
Op 27-5-2013 18:05, Jean-Marc Lasgouttes schreef: 24/05/2013 15:07, Vincent van Ravesteijn: By the way, this doesn't always work. The kill-gettext branch, for instance, has master merged in a few times to fix merge conflicts. Now, rebasing onto the merge-base does do no good. Vincent, I want to merge this kill-gettext branch now. Is there something I should do to make it less ugly? I do not understand why it requires such ugly merges in the middle. What about good old hand-made conflict resolution? Anyway, if you tell me to merge it as it is, it will be fine with me. JMarc It's not that ugly. It was required to immediately fix the merge conflicts at the moment they arise. First, if you would do it at the end, it would be more difficult and you might forget some conflicts. For example, you probably would forget the added 'intl' dependency of check_layout. Second, other people that would like to try out the feature could not merge it directly in their master because of the merge conflicts. So, we can offer them a branch that can be merged into master. Anyway, I rebased the branch onto master now. Shall I push it later ? Vincent
Re: [LyX features/empty-length] Latest changes from Uwe for tex2lyx and lyx2lyx
24/05/2013 15:07, Vincent van Ravesteijn: By the way, this doesn't always work. The kill-gettext branch, for instance, has master merged in a few times to fix merge conflicts. Now, rebasing onto the merge-base does do no good. Vincent, I want to merge this kill-gettext branch now. Is there something I should do to make it less ugly? I do not understand why it requires such ugly merges in the middle. What about good old hand-made conflict resolution? Anyway, if you tell me to merge it as it is, it will be fine with me. JMarc
Re: [LyX features/empty-length] Latest changes from Uwe for tex2lyx and lyx2lyx
Le 24/05/13 15:40, Vincent van Ravesteijn a écrit : Did you reset your local empty-length branch to 85e391e43 ? (That's your last commit before hell broke loose) OK, I think I pushed it correctly now. JMarc
Re: [LyX features/empty-length] Latest changes from Uwe for tex2lyx and lyx2lyx
On 05/24/2013 09:07 AM, Vincent van Ravesteijn wrote: By the way, this doesn't always work. The kill-gettext branch, for instance, has master merged in a few times to fix merge conflicts. Now, rebasing onto the merge-base does do no good. Yes, in that case, it would seem merging into master makes the most sense. # Now rebase against master git rebase master You could just as well had rebased to master in the previous step (avoiding the problem I stated above). It's somewhat easier, for me, at least, to handle these two steps separately: (i) Deal with cleaning up the history locally; (ii) Rebase (or merge), and fix the conflicts. Mixing the two tasks gets confusing. Richard
Re: [LyX features/empty-length] Latest changes from Uwe for tex2lyx and lyx2lyx
Did you reset your local empty-length branch to 85e391e43 ? (That's your last commit before hell broke loose) Vincent On Fri, May 24, 2013 at 3:18 PM, Jean-Marc Lasgouttes wrote: > Le 24/05/13 12:20, Vincent van Ravesteijn a écrit : > > I've reset the branch now to the last commit you made. All commits from >> master were somehow rebased or cherry-picked on top of the feature branch. >> >> You can merge it into master by: >> >>git checkout master >>git merge empty-length -m "Please supply a commit message instead of >> the default" >> > > I get lots of errors like: > > Auto-merging src/tests/test_layout > CONFLICT (add/add): Merge conflict in src/tests/test_layout > Auto-merging src/insets/InsetBox.cpp > Auto-merging src/frontends/qt4/qt_helpers.h > Auto-merging src/frontends/qt4/qt_helpers.**cpp > Auto-merging src/TextClass.cpp > CONFLICT (content): Merge conflict in src/TextClass.cpp > > These should not happen. > > JMarc >
Re: [LyX features/empty-length] Latest changes from Uwe for tex2lyx and lyx2lyx
Le 24/05/13 12:20, Vincent van Ravesteijn a écrit : I've reset the branch now to the last commit you made. All commits from master were somehow rebased or cherry-picked on top of the feature branch. You can merge it into master by: git checkout master git merge empty-length -m "Please supply a commit message instead of the default" I get lots of errors like: Auto-merging src/tests/test_layout CONFLICT (add/add): Merge conflict in src/tests/test_layout Auto-merging src/insets/InsetBox.cpp Auto-merging src/frontends/qt4/qt_helpers.h Auto-merging src/frontends/qt4/qt_helpers.cpp Auto-merging src/TextClass.cpp CONFLICT (content): Merge conflict in src/TextClass.cpp These should not happen. JMarc
Re: [LyX features/empty-length] Latest changes from Uwe for tex2lyx and lyx2lyx
On Fri, May 24, 2013 at 3:00 PM, Richard Heck wrote: > > My procedure for doing this kind of thing is similar but avoids the last > merge step > It is the question whether we want to have the merge commit, or we don't want it. If a feature consists of 20 small changes, it might be more useful to have a single merge commit on the master branch instead of 20 to avoid cluttering. > git checkout mybranch > # Make sure the history here is the way I want it to be, e.g.: > git log > git rebase -i HEAD~5 > That's `git merge-base master`. By the way, this doesn't always work. The kill-gettext branch, for instance, has master merged in a few times to fix merge conflicts. Now, rebasing onto the merge-base does do no good. > # Now rebase against master > git rebase master > You could just as well had rebased to master in the previous step (avoiding the problem I stated above). Vincent
Re: [LyX features/empty-length] Latest changes from Uwe for tex2lyx and lyx2lyx
My procedure for doing this kind of thing is similar but avoids the last merge step: git checkout mybranch # Make sure the history here is the way I want it to be, e.g.: git log git rebase -i HEAD~5 # Now rebase against master git rebase master # We'll push this branch to master using a custom command to do it git pushto master The script that implements pushto is attached. It has a few nice features. (i) It first shows you what commits will be pushed and then asks you if you want to proceed. (ii) It then pushes the commits one by one, as a way of dealing with the fact that our email script currently sends only one bulk email for the whole push. Activate the pushto script by putting it in your path and doing: git config --global alias.pushto=!git-pushto Richard #!/bin/bash REMOTE="origin"; RBRANCH="$1"; BRANCH=$(git br | grep '^\*' | cut -d' ' -f2); if [ -z "$RBRANCH" ]; then RBRANCH="$BRANCH"; if [ "$RBRANCH" != "master" -a "$RBRANCH" != "2.0.x" ]; then echo "Do you want to push to $RBRANCH?"; select answer in Yes No; do if [ "$answer" != "Yes" ]; then echo "Aborting push."; exit 1; break; else break; fi done fi fi if ! git push -n $REMOTE $BRANCH:$RBRANCH >/dev/null 2>&1; then echo "Branch is not up to date!"; exit 1; fi LOGS=$(git push -n $REMOTE $BRANCH:$RBRANCH 2>&1 | tail -n 1 | grep -v "Everything" | sed -e 's/^ *//' -e 's/ .*//'); if [ -z "$LOGS" ]; then echo "Everything up to date"; exit 0; fi echo $LOGS git log $LOGS; #Do we want to go ahead? echo echo "Do you want to push these commits to $RBRANCH?" select answer in Yes No; do if [ "$answer" != "Yes" ]; then exit 0; break; else break; fi done COMMITS=""; for i in `git log $LOGS | grep -P '^commit' | cut -d' ' -f2`; do COMMITS="$i $COMMITS"; done for i in $COMMITS; do git push $REMOTE $i:$RBRANCH; done
Re: [LyX features/empty-length] Latest changes from Uwe for tex2lyx and lyx2lyx
Le 24/05/13 12:20, Vincent van Ravesteijn a écrit : I've reset the branch now to the last commit you made. All commits from master were somehow rebased or cherry-picked on top of the feature branch. Thanks, I am not sure what I did wrong. You can merge it into master by: git checkout master git merge empty-length -m "Please supply a commit message instead of the default" Will do. or you can rebase onto master and fix the history: git checkout empty-length git rebase master -i "Remove" is not remove, right? Shouldn't I use squash instead? git checkout master git merge empty-length (this will fast-forward master) I understand this one; but the following ones made my head explode. So, what should I do about the kill-gettext branch now? JMarc
Re: [LyX features/empty-length] Latest changes from Uwe for tex2lyx and lyx2lyx
On Fri, May 24, 2013 at 10:46 AM, Jean-Marc Lasgouttes wrote: > Le 24/05/13 10:28, Jean-Marc Lasgouttes a écrit : > > The branch, empty-length, has been updated. >> >> - Log --**--** >> - >> >> commit 85e391e43a6d7188683dacae729475**e77597415d >> Author: Jean-Marc Lasgouttes >> Date: Wed May 22 15:50:44 2013 +0200 >> >> Latest changes from Uwe for tex2lyx and lyx2lyx >> >> I amended Uwe patches a bit, since empty width should be output as >>width "" >> in the LyX file. >> > > > Could someone (Vincent?) take a look at this branch and tell me why the > commits seem to be in random order wrt dates? What did I do wrong? Can I > merge it as it is? > > JMarc > I've reset the branch now to the last commit you made. All commits from master were somehow rebased or cherry-picked on top of the feature branch. You can merge it into master by: git checkout master git merge empty-length -m "Please supply a commit message instead of the default" or you can rebase onto master and fix the history: git checkout empty-length git rebase master -i git checkout master git merge empty-length (this will fast-forward master) or you can rebase onto master and fix the history and make a merge commit: git checkout empty-length git rebase master -i git checkout master git merge empty-length --commit -m "Message" (this will create a merge commit) or you can first fix history and then merge: git checkout empty-length git rebase -i `git merge-base master empty-length` git checkout master git merge empty-length -m "Please supply a commit message instead of the default" (this makes a merge commit) Vincent
Re: [LyX features/empty-length] Latest changes from Uwe for tex2lyx and lyx2lyx
Le 24/05/13 10:28, Jean-Marc Lasgouttes a écrit : The branch, empty-length, has been updated. - Log - commit 85e391e43a6d7188683dacae729475e77597415d Author: Jean-Marc Lasgouttes Date: Wed May 22 15:50:44 2013 +0200 Latest changes from Uwe for tex2lyx and lyx2lyx I amended Uwe patches a bit, since empty width should be output as width "" in the LyX file. Could someone (Vincent?) take a look at this branch and tell me why the commits seem to be in random order wrt dates? What did I do wrong? Can I merge it as it is? JMarc
