On 11/03/13 22:19, Caolán McNamara wrote:
> On Mon, 2013-03-11 at 22:04 +0100, Michael Stahl wrote:
>> that is one of the reasons why i'm of the opinion that using wildcards
>> in a build system is almost always a Bad Idea, trading a short-term
>> inconvenience for subtle breakages and surprises.
>
On 11 March 2013 17:14, Michael Stahl wrote:
> in the end it should look something like this:
>
> 1) instead of solver/ imagine some installation/ dir that is a runnable
>installation (LO and SDK and any help/l10n etc.)
>
> 2) */Package*.mk copies the files into the right place in installation
On Mon, 2013-03-11 at 22:04 +0100, Michael Stahl wrote:
> that is one of the reasons why i'm of the opinion that using wildcards
> in a build system is almost always a Bad Idea, trading a short-term
> inconvenience for subtle breakages and surprises.
The other "files not found" aren't using wildca
On 11/03/13 21:38, Caolán McNamara wrote:
> On Mon, 2013-03-11 at 17:14 +0100, Michael Stahl wrote:
>> actually that doesn't appear to be the case - none of the
>> dictionaries/Dictionary*.mk or */Zip*.mk use wildcard * to add files,
>> all list the files explicitly.
>
> But FWIW libexttextcat did
On Mon, 2013-03-11 at 17:14 +0100, Michael Stahl wrote:
> actually that doesn't appear to be the case - none of the
> dictionaries/Dictionary*.mk or */Zip*.mk use wildcard * to add files,
> all list the files explicitly.
But FWIW libexttextcat did use a pattern, for its fingerprints, and has
been
On 04/03/13 12:36, Bjoern Michaelsen wrote:
> On Mon, Mar 04, 2013 at 10:31:12AM +, Michael Meeks wrote:
>> Hi guys,
>>
>> Norbert pointed out to me that one of the slowest pieces of our install
>> is the:
>>
>> 'checking files with ARCHIVE flags' ...
>>
>> Phase in the make_inst
Hi David, *,
On Mon, Mar 4, 2013 at 11:26 PM, David Ostrovsky wrote:
>
> So let's pick up this ARCHIVE from file_python.scp and check what's going on
> there
> (i ommited non important pieces):
>
> File gid_File_Py_Python_Core
> #ifdef MACOSX
> Name = "LibreOfficePython.framework.zip";
>
On 2013-03-05 11:39, Michael Meeks wrote:
The deliverable to the install of the vast majority of external
projects is not a .zip file in my experience - but a .so / .dll or
, and lots that are (apparently) some hack-around scp2 so that it's
not necessary to list lots of individual files:
Hi Bjoern,
On Tue, 2013-03-05 at 00:22 +0100, Bjoern Michaelsen wrote:
> On Mon, Mar 04, 2013 at 11:26:00PM +0100, David Ostrovsky wrote:
> > Sure? I do want to see what those builds do ... because if they are doing
> > boolshit,
> > let's change that ;-)
>
> No, I dont want to change it as it w
Hi David,
On Mon, Mar 04, 2013 at 11:26:00PM +0100, David Ostrovsky wrote:
> Sure? I do want to see what those builds do ... because if they are doing
> boolshit,
> let's change that ;-)
No, I dont want to change it as it would mean becoming the maintainer for the
~90 external projects we have.
On Mon Mar 4 Bjoern Michaelsen wrote:
So I had a quick look at the above perl-foo and a grep on ARCHIVE in scp2 -- it
seems this is mostly done for external stuff like dictionaries etc. -- where we
do not have insight into what those builds do. And we also do not _want_ to
have insight into that
On Mon, Mar 04, 2013 at 10:31:12AM +, Michael Meeks wrote:
> Hi guys,
>
> Norbert pointed out to me that one of the slowest pieces of our install
> is the:
>
> 'checking files with ARCHIVE flags' ...
>
> Phase in the make_installer.pl foo, which burns a ton of CPU time for
Hi guys,
Norbert pointed out to me that one of the slowest pieces of our install
is the:
'checking files with ARCHIVE flags' ...
Phase in the make_installer.pl foo, which burns a ton of CPU time for
no aparently good reason.
Last I looked it seemed that we were u
13 matches
Mail list logo
