Zitat von Noel Grandin :
On 2012-05-04 14:11, d.ostrov...@idaia.de wrote:
Could you please provide error log?
Error looks like the isatty() definition is missing somehow? Perhaps
an include path thing?
Could you please compile idlc module (with make verbose=t to see the
commands)?
On 2012-05-04 14:11, d.ostrov...@idaia.de wrote:
Could you please provide error log?
Error looks like the isatty() definition is missing somehow? Perhaps an
include path thing?
make l10ntools
cd l10ntools && make -j 15 -rs gb_PARTIALBUILD=T
[ build CXX ] LexTarget/l10ntools/source/cfglex.
Zitat von Noel Grandin :
Thanks.
With your patch and Michael's "hack" patch, I can get as far as
building l10ntools, where it seems to be failing because of the
recent gbuild-ification.
Could you please provide error log?
Ciao
David
___
Libre
Thanks.
With your patch and Michael's "hack" patch, I can get as far as building
l10ntools, where it seems to be failing because of the recent
gbuild-ification.
On 2012-05-04 12:45, Matúš Kukan wrote:
On 3 May 2012 14:19, Noel Grandin wrote:
With your patch, if I specify the path cygwin st
On 3 May 2012 14:19, Noel Grandin wrote:
> With your patch, if I specify the path cygwin style, it fails very quickly.
>
> If I specify the path as "D:\" it gets much further but then fails in the
> bridges module.
Maybe you need to specify "D:/" ?
Also you can try
http://cgit.freedesktop.org/lib
I agree - rather just enforce that cygwin builds should be using make 3.82
On 2012-05-04 06:08, Jan Holesovsky wrote:
Hi Matus,
Matúš Kukan píše v Pá 04. 05. 2012 v 00:49 +0200:
If there is somebody who uses make 3.81 on _cygwin_ it should not be a
problem to upgrade ?
The @fast and @prague
Hi Matus,
Matúš Kukan píše v Pá 04. 05. 2012 v 00:49 +0200:
> If there is somebody who uses make 3.81 on _cygwin_ it should not be a
> problem to upgrade ?
The @fast and @prague tinderboxes use 3.81; but indeed, upgrading
shouldn't be a problem, because they use self-built make anyway. Please
i
On 3 May 2012 16:28, Noel Grandin wrote:
> Why are we playing substring games instead of using the cygpath utility to
> convert between cygwin-unix-style-paths and windows-paths ?
>
> Is it a speed issue?
Hmm, I think it is better because of speed, though I did not run a
single test for it.
And a
> Is it a speed issue?
If it is, one solution would be to require our own make fork on Cygwin
(it is very much recommended already), and add some suitable $(cygpath
...) function to it (probably two: cygpath_to_windows and
winpath_to_cygwin, or something), which would call the appropriate
Cygwin l
Why are we playing substring games instead of using the cygpath utility
to convert between cygwin-unix-style-paths and windows-paths ?
Is it a speed issue?
On 2012-05-03 16:20, Matúš Kukan wrote:
+# Convert path to native notation
+# First convert to unix style to avoid problems when
+# $(SRCD
On 3 May 2012 13:30, Michael Stahl wrote:
> Matus, is 8fd5ba3749aa740b3c060db775b42f15a5ce50a7 really necessary?
> it seems to make everything more complex..
It is if you want to build inside /home/
+# Convert path to native notation
+# First convert to unix style to avoid problems when
+# $(SR
On 2012-05-03 13:30, Michael Stahl wrote:
the attachment contains an utterly horrible workaround that you could
try out,
With your patch, if I specify the path cygwin style, it fails very quickly.
If I specify the path as "D:\" it gets much further but then fails in
the bridges module.
Bo
On 03/05/12 10:37, Noel Grandin wrote:
>
>
> On 2012-05-02 19:54, Michael Stahl wrote:
>> so i've added a --with-solver-and-workdir-root to do that on master
>
> Thanks, that's an awesome idea.
>
> But now I'm getting all kinds of weird errors, see the attached log.
the gbuild ones apparently
Interesting, my problem under Cygwin went away when I changed from this
--with-solver-and-workdir-root=/cygdrive/d
to this
--with-solver-and-workdir-root=d:\
My build is still running, but it's getting much further than it was
earlier today.
On 2012-05-02 19:54, Michael Stahl wrote:
so i've ad
On 2012-05-02 19:54, Michael Stahl wrote:
so i've added a --with-solver-and-workdir-root to do that on master
Thanks, that's an awesome idea.
But now I'm getting all kinds of weird errors, see the attached log.
Also, I think "make clean" will need to explicitly clean out the solver
and wor
On 02/05/12 14:42, Michael Stahl wrote:
> On 02/05/12 14:06, Noel Grandin wrote:
>> Hi
>>
>> I'm trying to use symlinks to speed up my windows tinderbox.
>> I've used an NTFS junction point (the windows equivalent of a symlink)
>> to make workdir and solver point at a ram-drive.
>>
>> But the IDL
On 02/05/12 14:06, Noel Grandin wrote:
> Hi
>
> I'm trying to use symlinks to speed up my windows tinderbox.
> I've used an NTFS junction point (the windows equivalent of a symlink)
> to make workdir and solver point at a ram-drive.
>
> But the IDL file processing is glitching with the errors be
Hi
I'm trying to use symlinks to speed up my windows tinderbox.
I've used an NTFS junction point (the windows equivalent of a symlink)
to make workdir and solver point at a ram-drive.
But the IDL file processing is glitching with the errors below. Any
ideas where to start looking to fix this?
18 matches
Mail list logo
