2011/4/6 Arnaud Charlet :
>> Since then, the behavior you're relying on has been adopted by POSIX, and
>> I think all or nearly all of the UNIX vendors have implemented it in their
>> own versions of ln, so these days you may no longer care.
>
> To be more precise, we adopted this scheme at least 1
> Since then, the behavior you're relying on has been adopted by POSIX, and
> I think all or nearly all of the UNIX vendors have implemented it in their
> own versions of ln, so these days you may no longer care.
To be more precise, we adopted this scheme at least 12 years ago on a wide
range of O
Arnaud Charlet writes:
> That's wrong. The above is
> $(LN_S) /full/path/to/a_file a_dir
> which is quite different from
> $(LN_S) a_file a_dir
> and will work equally well with ln or ln -s or cp -p.
This is not historically portable for ln -s. Passing in a directory as
the second argument
On 4/5/2011 12:50 PM, Arnaud Charlet wrote:
>> This:
>> $(LN_S) $(fsrcpfx)ada/$(f) $(RTSDIR)
>> fits that non-portable pattern
>
> That's wrong. The above is
>
> $(LN_S) /full/path/to/a_file a_dir
>
> which is quite different from
>
> $(LN_S) a_file a_dir
>
> and will work equally well wi
> According to 'info Autoconf --index LN_S' as quoted by Ralf, it is not
> *portable* to do
> $(LN_S) a_file a_dir
> because it behaves differently depending on whether LN_S is "ln -s",
> "ln" (or, as in this case, "cp -p").
That is certainly true.
> This:
> $(LN_S) $(fsrcpfx)ada/$(f)
On 4/5/2011 12:11 PM, Arnaud Charlet wrote:
>> As a side issue, it ALSO seems to me that Ada's Mafile.in is doing it
>> wrong, given Ralf's statements above:
>>
>> # Copy target independent sources
>> $(foreach f,$(ADA_INCLUDE_SRCS) $(LIBGNAT_SRCS), \
>> $(LN_S) $(fsrcpfx)ada
> As a side issue, it ALSO seems to me that Ada's Mafile.in is doing it
> wrong, given Ralf's statements above:
>
> # Copy target independent sources
> $(foreach f,$(ADA_INCLUDE_SRCS) $(LIBGNAT_SRCS), \
> $(LN_S) $(fsrcpfx)ada/$(f) $(RTSDIR) ;) true
>
> But as this isn't s
On 4/5/2011 10:21 AM, Ralf Wildenhues wrote:
> * Charles Wilson wrote on Tue, Apr 05, 2011 at 04:15:02PM CEST:
>> On 4/5/2011 9:21 AM, Arnaud Charlet wrote:
I'm one of the MSys "devs" (if you want to call the sporadic process of
updating MSys "development"). I'll take a look at implement
* Charles Wilson wrote on Tue, Apr 05, 2011 at 04:15:02PM CEST:
> On 4/5/2011 9:21 AM, Arnaud Charlet wrote:
> >> I'm one of the MSys "devs" (if you want to call the sporadic process of
> >> updating MSys "development"). I'll take a look at implementing
> >>ln -s file dir
> >> as synonymous wi
On 4/5/2011 9:21 AM, Arnaud Charlet wrote:
>> I'm one of the MSys "devs" (if you want to call the sporadic process of
>> updating MSys "development"). I'll take a look at implementing
>> ln -s file dir
>> as synonymous with
>> ln -s file dir/basename-of-file
>> in the next few days.
>
>
> I'm one of the MSys "devs" (if you want to call the sporadic process of
> updating MSys "development"). I'll take a look at implementing
> ln -s file dir
> as synonymous with
> ln -s file dir/basename-of-file
> in the next few days.
Thanks, although the case we're really interested
On 4/5/2011 6:22 AM, Kai Tietz wrote:
> 2011/4/5 Arnaud Charlet :
>>> I know about that. And in fact I am use Wine for doing an native
>>> compile. Nevertheless most users using msys for native windows. Btw
>>> that it would work on cygwin is more theory,
>>
>> It's not theory, it's what e.g. we d
2011/4/5 Arnaud Charlet :
>> I know about that. And in fact I am use Wine for doing an native
>> compile. Nevertheless most users using msys for native windows. Btw
>> that it would work on cygwin is more theory,
>
> It's not theory, it's what e.g. we do at AdaCore so it's very much
> reality rath
> I know about that. And in fact I am use Wine for doing an native
> compile. Nevertheless most users using msys for native windows. Btw
> that it would work on cygwin is more theory,
It's not theory, it's what e.g. we do at AdaCore so it's very much
reality rather than theory.
> Sorry, here I a
2011/4/5 Arnaud Charlet :
>> I agree, and I read the threads about that there on mingw.org. I
>> don't see a good chance that it get fixed soon there. Nevertheless is
>> the msys-environment the only way to do a full bootstrap of native gcc
>> toolchain, so I would simply love to have this work-a
> I agree, and I read the threads about that there on mingw.org. I
> don't see a good chance that it get fixed soon there. Nevertheless is
> the msys-environment the only way to do a full bootstrap of native gcc
> toolchain, so I would simply love to have this work-a-rounded it in
> gcc. But wel
2011/4/5 Arnaud Charlet :
>> Well, there is a bug AFAICS. Issue is that 'ln -s file dir' fails, but
>> 'ln -s file file1' works. See for this thread
>> http://lists.zerezo.com/mingw-users/msg03642.html, where this is
>> described. So it might be also a valid fix here to append to directory
>> the $
> Well, there is a bug AFAICS. Issue is that 'ln -s file dir' fails, but
> 'ln -s file file1' works. See for this thread
> http://lists.zerezo.com/mingw-users/msg03642.html, where this is
> described. So it might be also a valid fix here to append to directory
> the $f again.
OK, so it's indeed a
2011/4/5 Arnaud Charlet :
>> Hmm, AFAICS is in Mafile.in the following line present:
>>
>> # Copy target independent sources
>> $(foreach f,$(ADA_INCLUDE_SRCS) $(LIBGNAT_SRCS), \
>> $(LN_S) $(fsrcpfx)ada/$(f) $(RTSDIR) ;) true
>>
>> which seems to me the cause for this patch.
>
>
> Hmm, AFAICS is in Mafile.in the following line present:
>
> # Copy target independent sources
> $(foreach f,$(ADA_INCLUDE_SRCS) $(LIBGNAT_SRCS), \
> $(LN_S) $(fsrcpfx)ada/$(f) $(RTSDIR) ;) true
>
> which seems to me the cause for this patch.
The above loop will link/copy file
2011/4/5 Arnaud Charlet :
>> as described in PR, there is a failure to copy adainclude/adalib
>> libraries in MSYS.
>
> The PR does not give any details as to what exact error message you are
> getting, at which step, and what Makefile rule/line is causing this behavior.
>
> I'm surprised by LN_S i
> as described in PR, there is a failure to copy adainclude/adalib
> libraries in MSYS.
The PR does not give any details as to what exact error message you are
getting, at which step, and what Makefile rule/line is causing this behavior.
I'm surprised by LN_S is used to link directories,this look
Hello,
as described in PR, there is a failure to copy adainclude/adalib
libraries in MSYS.
This is caused by LN_S set to cp -p for MSYS. This option for cp is
not suitable to copy folder to folder in MSYS, and the additional
option -r is necessary.
ChangeLog
2011-04-04 Kai Tietz
PR ada
23 matches
Mail list logo
