> I am solving this problem by
A patch has already been submitted. Please test it using lyx' User's guide.
Bo
> This is actually also related to the original problem with [Embedding
> discussion 1], do we want multiple entries for multiple insets
> referring to the same file?
I am solving this problem by
1, store a list of ParConstIterator for multiple insets in a EmbeddedFile item.
2. display the file i
Andre (I suppose),
What's the state of src/frontends/ now? Safe to commit, or shall we
continue holding off? The last bit of the modules stuff is the frontend
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown Un
Infact at line 9 of src/frontends/controllers/Makefile.am:
SOURCEFILES = \
Dialog.cpp \
Dialog.cpp \
[...]
Don't know why, disabling shared, linking goes through, instead.
T.
Tommaso Cucinotta ha scritto:
Hi all,
when compiling with --enable-shared (that would seem a good
switch
Hi all,
when compiling with --enable-shared (that would seem a good
switch to enable at a first glance), linking fails due to a double
inclusion of Dialog.o. Details follow (version from SVN).
T.
$ ./configure --disable-debug --disable-stdlib-debug
--enable-optimization=-O --disable-pch --e
José Matos <[EMAIL PROTECTED]> writes:
> So I have committed a new version with this fixed.
So it works with python 2.3 too? good.
I will commit that to 1.5 too, since this is where it is useful now.
> The is a direct replacement for postats.sh later I will do other changes
> like to write
Bo Peng ha scritto:
I don't know how useful that would be. They'd have to unpack the files,
install them, run texhash (or whatever), just as they do now. Right?
Not really. If you put a .cls in your document directory, lyx can make
use of it.
Infact, I was just thinking to custom .cls, .bs
> I don't know how useful that would be. They'd have to unpack the files,
> install them, run texhash (or whatever), just as they do now. Right?
Not really. If you put a .cls in your document directory, lyx can make
use of it. That is to say, if your customized class is simple enough
(a single fil
On Friday 07 September 2007 18:26:36 Tommaso Cucinotta wrote:
> (of course, you could argue this is a problem of LaTeX
> package maintainers, not yours ...).
You are right here. :-)
It would be crazy to try to fix this problem inside lyx. :-)
--
José Abílio
Tommaso Cucinotta wrote:
Hi,
concerning the embedding feature I've quickly read about
on the list, will it be possible to embed even system-level
dependent LaTeX files (e.g. .sty, .cls) ? Often, while
exchanging LaTeX files with co-workers using different
operating systems (e.g. Win <-> Lin), it
Hi,
concerning the embedding feature I've quickly read about
on the list, will it be possible to embed even system-level
dependent LaTeX files (e.g. .sty, .cls) ? Often, while
exchanging LaTeX files with co-workers using different
operating systems (e.g. Win <-> Lin), it happens that the
differen
Dear all,
Thanks to Edwin, the embedding dialog is working again. It now has a
list of embedded files, with embedding status (true/false) indicated
by checkboxes. There are five buttons: select (embed selected files),
unselect (dis-embed selected files), add (add a file), extract
(extract selected
On Friday 07 September 2007 16:10:11 Jean-Marc Lasgouttes wrote:
> pegase: python -V
> Python 2.3.4
That is the problem. Python 2.3 does not have support for Asian encodings.
This only happens for python 2.4. In this though it does not matter since the
name is ascii.
FWIW this should be the
On Fri, Sep 07, 2007 at 05:43:52PM +0200, Jean-Marc Lasgouttes wrote:
> Enrico Forestieri <[EMAIL PROTECTED]> writes:
>
> > I would like to solve the linking problem ASAP, so I propose to apply
> > the patch and possibly tweak it later. Jürgen, Ok for branch, too?
>
> This is OK with me.
Applie
> > I agree, but the problem is that sometimes it is not easy to insert
> > all needed files (.inc, .modules, .sty) so manual adjustment may be
> > needed. This can be postponed until we implement this feature.
>
> If we can't do it, then we should not try to bundle layout files.
> Normal users are
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes:
> Jean-Marc Lasgouttes wrote:
>> I am going to commit to trunk and I propose to apply to branch too.
>
> The version you just committed looks good for branch as well. Go ahead.
Done.
JMarc
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes:
> Are you sure these are safe? Optimization is certainly welcome (I just had to
> downgrade to 1.4.5 on my Laptop because 1.5svn is unbearably slow :-().
Is it related to one of the 'slowness' bugs that we have? This is very
unfortunate...
JMarc
"Bo Peng" <[EMAIL PROTECTED]> writes:
> I agree, but the problem is that sometimes it is not easy to insert
> all needed files (.inc, .modules, .sty) so manual adjustment may be
> needed. This can be postponed until we implement this feature.
If we can't do it, then we should not try to bundle la
On Fri, Sep 07, 2007 at 11:08:00AM +0200, Jürgen Spitzmüller wrote:
> Enrico Forestieri wrote:
> > Done. I would also suggest the attached patch.
>
> OK.
Committed.
--
Enrico
Enrico Forestieri <[EMAIL PROTECTED]> writes:
> I would like to solve the linking problem ASAP, so I propose to apply
> the patch and possibly tweak it later. Jürgen, Ok for branch, too?
This is OK with me.
JMarc
On Fri, Sep 07, 2007 at 10:01:48AM +0200, Jean-Marc Lasgouttes wrote:
> Enrico Forestieri <[EMAIL PROTECTED]> writes:
>
> > Here are the patches for trunk and branch. Those with Qt 4.1, on *nix
> > should register the fonts with fontconfig by themselves (or use the
> > xft-fonts package), on wind
> + // FIXME, Bo this does nothing
> bool mode = false;
> + // FIXME: Bo, this is not used
> + // FIXME: Bo, this is not used
> + //int row = filesLW->row(*it);
BTW, these are the consequences of the removal of AUTO feature. The
dialog is being rewritten.
Bo
> > What do you think?
>
> I do not think that it should be possible to add arbitrary files manually.
> LyX is a writing tool, not an archiver. The .layout and .cls files would be
> the only ones needing a setting in the .lyx file.
I agree, but the problem is that sometimes it is not easy to inser
Bo Peng wrote:
> I would suggest that we add the manifest file to .lyx header, and
> *separate* embedding information from whether or not the .lyx file
> will be bundled. That is to say, we can allow users to set things like
> 'embed this file if saved in bundled format', and 'embed .layout
>
José Matos <[EMAIL PROTECTED]> writes:
> On Thursday 06 September 2007 14:11:08 Jean-Marc Lasgouttes wrote:
>> BTW, rewriting the postats.sh script in python would be nice :)
>>
>> JMarc
>
> Like the attached script?
Looks great. There is a problem though:
pegase: make i18n.inc
(cd ../../1.5.x/p
Helge Hafting wrote:
> Why? An old LyX will open files created with the new
> LyX just fine - because the .lyx file don't differentiate
> between the wrapfig and floatflt latex packages.
>
> The .lyx file format just specifies a "wrapped figure",
> which either of these packages implement.
But the
On Friday 07 September 2007 15:40:54 Helge Hafting wrote:
> If you still need a version change (for political reasons?)
> please give me a hint on how I change the file format
> and add the do-nothing-at-all conversion. I can then add
> that to my wrapfig patch.
The point that has been raised is
Jean-Marc Lasgouttes wrote:
Helge Hafting <[EMAIL PROTECTED]> writes:
* LyX files where the wrapped figure was silently lost
will now produce output. :-)
It is said in the documentation that wrapfig does not work inside
enumerations. What do we do about that?
A quick test with a
Richard Heck wrote:
> Would you need one if you DIDN'T change the \begin -- \end commands?
I would say yes. You never know how different the output might be. If we
detect a fundamental difference in advance, we cannot do anything if we don't
have a format change.
Jürgen
> you need to pass the right flags to the listwidget item as in attached.
>
> i didn't look at the logic, but guess you can take it from here
This is exactly what I wanted. Thank you very much!
Bo
Jürgen Spitzmüller wrote:
Helge Hafting wrote:
It is easy enough to make a patch that simply replaces
floatflt with wrapfig, by changing the \usepackage
as well as the \begin -- \end commands that LyX outputs.
Would that be an acceptable starting point?
I think this can be done without chan
> Source code? What do you mean?
>
> What kind of things do you intend to do with the layout?
Currently, if .layout is kept with .lyx, you can open the .lyx file
without installing .layout file to ~/.lyx. The same goes with .cls.
That is to say, if we embed some customized .layout and .cls file to
On Thursday 06 September 2007 14:11:08 Jean-Marc Lasgouttes wrote:
> BTW, rewriting the postats.sh script in python would be nice :)
>
> JMarc
Like the attached script?
--
José Abílio
postats.py
Description: application/python
"Bo Peng" <[EMAIL PROTECTED]> writes:
> However, to achieve lossless conversion, we also need to keep
> information about manually added files such as layout, source code
> etc, and which files to embed (assuming that we want to keep this
> feature).
Source code? What do you mean?
What kind of
Jean-Marc Lasgouttes wrote:
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
The worst part is of course that even if you tweak a text
wrap float so it displays, it may disappear later anyway as
editing elsewhere changes the page break locations.
Is there a different latex package th
Helge Hafting <[EMAIL PROTECTED]> writes:
> * LyX files where the wrapped figure was silently lost
> will now produce output. :-)
It is said in the documentation that wrapfig does not work inside
enumerations. What do we do about that?
JMarc
About manifest file and lossless conversion between bundled and
plain-text formats:
It has been clear that we need to keep the original filename
information to pack/unpack a bundled .lyx file. Such information can
be saved in a manifest file, or along with the insets, yet to be
decided.
However,
Uwe Stöhr wrote:
Helge Hafting schrieb:
I see no problem telling users that we have some feature that
doesn't always work as intended. But they need a warning,
if we're going to provide floatflt.
But users who don't have problems with wrap floats will be spammed
with a warning that only conf
Replacing floatflt with wrapfig wasn't that hard, so I made this
patch. I tested it also:
* Old LyX files with wrapped regions still opens just fine,
because I did not change anything in the .lyx file format.
(Such changes will be necessary if we later want to
support extra wrapfig options
Darren Freeman <[EMAIL PROTECTED]> writes:
> Don't forget that it only uses the pre-compiled header for the first
> #include. To get the benefits you still have to include all the project
> includes from one header. Lyx isn't doing this, right?
Look at things like src/pch.h.
JMarc
On Fri, 2007-09-07 at 09:25 +0100, José Matos wrote:
> On Friday 07 September 2007 08:25:30 Darren Freeman wrote:
> > Check out gcc's new precompiled header functionality.
> > http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html
> >
> > Basically gcc-3.4 and newer allow you to dump the state
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> FYI, I have transferred the current_font and real_current_font from
> Text to Cursor.
I _think_ we can actually get rid of real_current_font, which AFAIUI
is only current_font realized against the paragraph font.
JMarc
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Martin Vermeer wrote:
>> On Sun, Sep 02, 2007 at 04:08:28PM +0200, Abdelrazak Younes wrote:
>>> Could someone please elaborate on what is the purpose of this?
>>>
>>> Abdel.
>>
>> Yes... this is how the text inside an inset receives the font from the
Jürgen Spitzmüller wrote:
Helge Hafting wrote:
It is easy enough to make a patch that simply replaces
floatflt with wrapfig, by changing the \usepackage
as well as the \begin -- \end commands that LyX outputs.
Would that be an acceptable starting point?
I think this can be done without chan
Uwe Stöhr wrote:
But in general whenever you want to use a program, you have to read a
manual how to use it.
Well, I don't know. It's true that some people do read the manual, but
it's a sad program if you HAVE to read the manual to use it, and you
don't really have to read LyX's to use it. Th
Helge Hafting wrote:
> It is easy enough to make a patch that simply replaces
> floatflt with wrapfig, by changing the \usepackage
> as well as the \begin -- \end commands that LyX outputs.
>
> Would that be an acceptable starting point?
>
> I think this can be done without changing the file format
Alfredo Braunstein wrote:
> I did it. I assume no status.15x entry is needed because it's just
> optimization.
Agreed, if this optimization does not show up in significantly better
performance or something.
Jürgen
Jean-Marc Lasgouttes wrote:
> I am going to commit to trunk and I propose to apply to branch too.
The version you just committed looks good for branch as well. Go ahead.
Jürgen
Alfredo Braunstein <[EMAIL PROTECTED]> writes:
> I don't think it's possible unfortunately, for the reasons in my other post.
> We could have a O(1) RandomAccessList::getIterator(int pos) but it's
> obviously not so cool ;-) And it doesn't work for advancing an existing
> iterator.
I am not sure
Helge Hafting schrieb:
We can't tell users that certain functions are broken, either we
remove this function or fix it. when you think it is broken.
>
I see no problem telling users that we have some feature that
doesn't always work as intended. But they need a warning,
if we're going to provi
Jean-Marc Lasgouttes wrote:
> I would prefer to keep the current LyX format as it is (reference to
> external stuff only) and have the manifest provide a table that
> relates external paths to internal ones. This would mean that the .lyx
> file is 100% identical in embedded and non-embedded mode.
(Refer to the 'mark the text wrap float "broken"' for why.)
Wrapfig seems to work better than floatflt, at least wrapfig
outputs the figure in a case where floatflt silently looses it.
It is easy enough to make a patch that simply replaces
floatflt with wrapfig, by changing the \usepackage
as we
Jean-Marc Lasgouttes wrote:
> Alfredo Braunstein <[EMAIL PROTECTED]>
> writes:
>
>> Jean-Marc Lasgouttes wrote:
>>
>>> I guess we need a erase(pos_type).
>>
>> grep boost::next *cpp | wc
>> 37 1852583
>>
>> A slightly different idea: I wonder if a specialization of advance for
>> Ran
Alfredo Braunstein wrote:
Helge Hafting wrote:
If they work immediately but disappear later after a page 1 edit moved the
page breaks - well yuck. I consider it normal use to not read about
every little piece of functionality in the docs, and the failure mode
here is nasty. Information loss
Alfredo Braunstein <[EMAIL PROTECTED]> writes:
> Jean-Marc Lasgouttes wrote:
>
>> I guess we need a erase(pos_type).
>
> grep boost::next *cpp | wc
> 37 1852583
>
> A slightly different idea: I wonder if a specialization of advance for
> RandomAccessList::iterator would get us an inst
Jürgen Spitzmüller wrote:
> Alfredo Braunstein wrote:
>> It would be nice if someone else had a look at them though, just to be
>> safer.
>
> OK. If you feel confident about it, you can commit.
I did it. I assume no status.15x entry is needed because it's just
optimization.
A/
Helge Hafting wrote:
> If they work immediately but disappear later after a page 1 edit moved the
> page breaks - well yuck. I consider it normal use to not read about
> every little piece of functionality in the docs, and the failure mode
> here is nasty. Information loss with no warning. Now,
Uwe Stöhr wrote:
> This patch adds (Broken) to the insert->float->text wrap float
> entry, so it becomes
>
> Insert->Float->Text wrap float (Broken)
>
> This because it _is_ broken. I don't know of any LaTeX version
> where this thing works well at all.
Veto!
We can't tell users that certain fun
Jean-Marc Lasgouttes wrote:
Helge Hafting <[EMAIL PROTECTED]> writes:
This patch adds (Broken) to the insert->float->text wrap float
entry, so it becomes
Insert->Float->Text wrap float (Broken)
I would certainly oppose that, since the menu entry would be even more
disturbing.
I did
Alfredo Braunstein wrote:
> Jean-Marc Lasgouttes wrote:
>
>> I guess we need a erase(pos_type).
>
> grep boost::next *cpp | wc
> 37 1852583
>
> A slightly different idea: I wonder if a specialization of advance for
> RandomAccessList::iterator would get us an instant noticeable per
Jean-Marc Lasgouttes wrote:
> I guess we need a erase(pos_type).
grep boost::next *cpp | wc
37 1852583
A slightly different idea: I wonder if a specialization of advance for
RandomAccessList::iterator would get us an instant noticeable performance
improvement (because boost::next us
Alfredo Braunstein <[EMAIL PROTECTED]> writes:
> Jean-Marc Lasgouttes wrote:
>
>
> + boost::next(plist.begin(),old.pit())->params().startOfAppendix(soa);
>
> Better to use plist[old.pit()] here.
I kept what was the style of the function. But obviously you are right:)
>
> + plist.erase(bo
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
> http://bugzilla.lyx.org/show_bug.cgi?id=4212
>
> This patch consists of two different parts fixing the two different
> problems described in this bug. These bugs have been with us forever,
> AFAICS, but the fixes are trivial.
>
> I am going to com
Jean-Marc Lasgouttes wrote:
+ boost::next(plist.begin(),old.pit())->params().startOfAppendix(soa);
Better to use plist[old.pit()] here.
+ plist.erase(boost::next(plist.begin(), old.pit()));
Here it's not possible :-(
PS: Maybe we should implement a way to get the iterator at a certa
http://bugzilla.lyx.org/show_bug.cgi?id=4212
This patch consists of two different parts fixing the two different
problems described in this bug. These bugs have been with us forever,
AFAICS, but the fixes are trivial.
I am going to commit to trunk and I propose to apply to branch too.
JMarc
sv
Martin Vermeer wrote:
> Just adjustment... and I collided with Abdel. That's why two changesets,
> 20102 and 20103.
Ok these were included in the (revised) list.
A/
Georg Baum <[EMAIL PROTECTED]> writes:
> Bo Peng wrote:
>
>> There is another possibility (compromise):
>>
>> 1. we keep original file information (that would store in the
>> plain-text .lyx file) so that we can easily locate the external
>> counterpart of an embedded file. This would require a ma
Jean-Marc Lasgouttes wrote:
> Alfredo Braunstein <[EMAIL PROTECTED]>
> writes:
>
>> And I still don't understand why there are two cvs lists. Does lyx-cvs
>> get all commit logs, or also just a "selection"? Why don't all of you use
>> lyx-cvs instead of cvslog?
>
> The problem is to limit the pe
Bo Peng wrote:
>> > Then, you lose the original file information.
>>
>> I thought that you stored this info for all files.
>
> I do, but if I use the embedded or not solution, I can throw away
> external file information.
But you do not need to throw it away! Especially if you still need this
in
On Fri, 07 Sep 2007 10:24:20 +0200
Alfredo Braunstein <[EMAIL PROTECTED]> wrote:
> Martin Vermeer wrote:
>
> > On Thu, Sep 06, 2007 at 11:33:52PM +0200, Alfredo Braunstein wrote:
> >> Alfredo Braunstein wrote:
> >>
> >> >> I don't have time to act on this until saturday so feel free to change
>
Alfredo Braunstein <[EMAIL PROTECTED]> writes:
> And I still don't understand why there are two cvs lists. Does lyx-cvs get
> all commit logs, or also just a "selection"? Why don't all of you use
> lyx-cvs instead of cvslog?
The problem is to limit the people who can send to lyx-cvs to people
tha
Bo Peng wrote:
> There is another possibility (compromise):
>
> 1. we keep original file information (that would store in the
> plain-text .lyx file) so that we can easily locate the external
> counterpart of an embedded file. This would require a manifest file
> unless the 'not-within-document-d
On Friday 07 September 2007 10:03:49 Alfredo Braunstein wrote:
> This is "funny". If this cvslog list is useful, I want to receive *all*
> commit logs, not only the ones of people that decide to subscribe. So it's
> the svn server that should send the messages, not the commiters.
>
> And I still d
Alfredo Braunstein <[EMAIL PROTECTED]> writes:
>
> But but I don't want to be subscribed to some cvs spam list! I want to
> browse commit logs in gmane.
I *think* that you can be subscribed but suspend the sending of messages.
> What's this weird subscription stuff anyway, it should be the oth
Enrico Forestieri wrote:
> Done. I would also suggest the attached patch.
OK.
Jürgen
Alfredo Braunstein wrote:
> It would be nice if someone else had a look at them though, just to be
> safer.
OK. If you feel confident about it, you can commit.
Jürgen
Martin Vermeer wrote:
> All done, thanks. Is this big enough for a status file entry?
Not sure. I guess not.
Jürgen
José Matos wrote:
> On Friday 07 September 2007 09:34:26 Alfredo Braunstein wrote:
>> Sigh ok, I'll do it. What a waste of resources...
>
> Did you notice the mailman above?
> That means that you can be a member of a list, that allows you to post,
> and
> opt not to receive messages. What i
On Friday 07 September 2007 09:34:26 Alfredo Braunstein wrote:
> Sigh ok, I'll do it. What a waste of resources...
Did you notice the mailman above?
That means that you can be a member of a list, that allows you to post, and
opt not to receive messages. What is the problem with this option?
Jean-Marc Lasgouttes wrote:
> Alfredo Braunstein <[EMAIL PROTECTED]>
> writes:
>
>> José Matos wrote:
>>
>>> On Thursday 06 September 2007 17:15:13 Jürgen Spitzmüller wrote:
probably because they do not appear on lyx-cvs (at least I don't have
them).
>>>
>>> You are not the only one. W
On Thursday 06 September 2007 20:52:00 Enrico Forestieri wrote:
> Ok, I will do. Notice that most probably there are other images that
> could benefit from these small tweaks. I don't want to tackle that
> sistematically, but to act when something hurts my eyes. May I be
> permitted in advance to d
On Friday 07 September 2007 08:25:30 Darren Freeman wrote:
> Check out gcc's new precompiled header functionality.
> http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html
>
> Basically gcc-3.4 and newer allow you to dump the state of the compiler
> to disc after your headers are compiled, and
Martin Vermeer wrote:
> On Thu, Sep 06, 2007 at 11:33:52PM +0200, Alfredo Braunstein wrote:
>> Alfredo Braunstein wrote:
>>
>> >> I don't have time to act on this until saturday so feel free to change
>> >> that if you want.
>> >
>> > I don't have time either unfortunately. I'll be a rather busy
Andre Poenitz <[EMAIL PROTECTED]> writes:
> On Thu, Sep 06, 2007 at 09:31:48AM +0200, Abdelrazak Younes wrote:
>> >Note that I did not really move anything from src/* to
>> >src/frontends/qt4/*. All the strings in the current GuiAbout dialog
>> >already lived soemewehe under src/frontends/*
>>
>>
Alfredo Braunstein <[EMAIL PROTECTED]> writes:
> José Matos wrote:
>
>> On Thursday 06 September 2007 17:15:13 Jürgen Spitzmüller wrote:
>>> probably because they do not appear on lyx-cvs (at least I don't have
>>> them).
>>
>> You are not the only one. We need to add Alfedro to the cvslog mailin
Darren Freeman <[EMAIL PROTECTED]> writes:
> On Thu, 2007-09-06 at 18:51 +0100, José Matos wrote:
>> I am not reticent. I am still compiling. :-(
>>
>> That is why I like André's goal to reduce the compile time. Does anyone
>> has
>> some simple step by step procedure to make ccache (or any
Georg Baum <[EMAIL PROTECTED]> writes:
> This is an orthogonal issue. A text archive format would enable me to put
> the whole archive in svn, and I would never forget to add external figures
> to svn. But this has nothing to do with auto.
Personally, I would prefer a directory format, if we can
On Thu, 2007-09-06 at 20:32 +0200, Andre Poenitz wrote:
> ccache is dead easy.
>
> As root
>
> ln -s /usr/local/bin/gcc /usr/bin/ccache
> ln -s /usr/local/bin/g++ /usr/bin/ccache
Oh god no! You'll (try to) overwrite /usr/bin/ccache!
:)
Have fun,
Darren
PS. I do that too, sometimes :D
Enrico Forestieri <[EMAIL PROTECTED]> writes:
> Here are the patches for trunk and branch. Those with Qt 4.1, on *nix
> should register the fonts with fontconfig by themselves (or use the
> xft-fonts package), on windows should install the fonts. Who is not
> willing (or cannot) upgrade pays a sma
you need to pass the right flags to the listwidget item as in attached.
i didn't look at the logic, but guess you can take it from here
(check out the fixme's too)
-Original Message-
From: Bo Peng [mailto:[EMAIL PROTECTED]
Sent: Fri 9/7/07 5:28
To: LyX Mechanics
Subject: Please help i
On Thu, 2007-09-06 at 18:51 +0100, José Matos wrote:
> I am not reticent. I am still compiling. :-(
>
> That is why I like André's goal to reduce the compile time. Does anyone has
> some simple step by step procedure to make ccache (or any other compiler
> cache) work. It is really frustrati
91 matches
Mail list logo
