[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bugs #10577] Fix symlinks for use on Windows
From: |
Nicola Pero |
Subject: |
[bugs #10577] Fix symlinks for use on Windows |
Date: |
Thu, 04 Nov 2004 03:53:12 -0500 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 |
This mail is an automated notification from the bugs tracker
of the project: GNUstep.
/**************************************************************************/
[bugs #10577] Latest Modifications:
Changes by:
Nicola Pero <n.pero@mi.flashnet.it>
'Date:
Thu 11/04/2004 at 08:47 (GMT)
What | Removed | Added
---------------------------------------------------------------------------
Category | Base/Foundation | Makefiles
Assigned to | fedor | nico
------------------ Additional Follow-up Comments ----------------------------
I fixed this on CVS. I suspect 'ln -s -f' might be unportable so I implemented
a slightly different mechanism with a new make variable RM_LN_S containing the
command used to remove a 'symlink' (/hard copy on mingw32) before creating /
recreating it.
I tested the changes on linux by hacking my config.make and replacing 'ln -s'
with 'cp -r'. It works for me.
Please could you try from CVS and report if the new code works on mingw32 as
well.
Thanks!
/**************************************************************************/
[bugs #10577] Full Item Snapshot:
URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=10577>
Project: GNUstep
Submitted by: Adam Fedor
On: Mon 10/04/2004 at 22:59
Category: Makefiles
Severity: 3 - Ordinary
Item Group: Bug
Resolution: None
Privacy: Public
Assigned to: nico
Status: Open
Summary: Fix symlinks for use on Windows
Original Submission: From: andre levy <gsalevy@almonde.com>
Date: September 16, 2004 10:10:04 AM MDT
To: discuss-gnustep@gnu.org
Subject: gnustep-make for windows: linked directory is not really usable
Hi all,
I'm using gnustep-make 1.10.0. to build my application.
I'm also using mingw-3.1.0-1 for gcc3.2 and msys-1.0.10 to run make.
when I run 'make' my project is compiled.
when I later on run 'make debug=yes' the compilation is interrupted with a
message like:
rm: 'obj' is a directory
ln: 'obj': cannot overwrite directory
I run into the same problem when I try to re-make a framework. it complains
that 'Current' is a directory...
Follow-up Comments
------------------
-------------------------------------------------------
Date: Thu 11/04/2004 at 08:47 By: Nicola Pero <nico>
I fixed this on CVS. I suspect 'ln -s -f' might be unportable so I implemented
a slightly different mechanism with a new make variable RM_LN_S containing the
command used to remove a 'symlink' (/hard copy on mingw32) before creating /
recreating it.
I tested the changes on linux by hacking my config.make and replacing 'ln -s'
with 'cp -r'. It works for me.
Please could you try from CVS and report if the new code works on mingw32 as
well.
Thanks!
-------------------------------------------------------
Date: Wed 11/03/2004 at 11:49 By: Patrick Middleton <patrickx>
Filesystem links on Windows are a dead loss. Possibly the Cygwin and MinGW
crews will get round one day to implementing 'ln' in terms of Windows
shortcuts, but I hope not: that'd be yet more incompatible semantics with which
to deal.
NeXT^WApple never bothered making the ProjectBuilder pb_makefile system work
with soft links on Windows. A case in point: they'd have used soft links when
building a framework so that Name.framework/Name pointed to
Name.framework/Versions/Current/Name , which in turn pointed to
Name.framework/Versions/{ExplicitLatestVersion}/Name . Which would have been
useless on Windows anyway as versioned frameworks wouldn't work, because the
dll loading mechanism is going to find the current Name.dll , whatever that may
be, in .../Library/Tools rather than the appropriate versioned dll from within
.../Library/Frameworks/Name.framework.
Lately I have been trying to build stuff, notably ProjectCenter 0.4.0 on
WindowsXP/MinGW/GNUstep base 1.10.0 and getting all sorts of build-related
grief.
Recent revisions to $GNUSTEP_SYSTEM_ROOT/Library/Makefiles/config.make have
introduced a make macro LN_S . By setting that to 'echo no ln -s' on MinGW,
and adding similar macros for rm -f and rm -rf , and setting RM_F to be rm -rf
on MinGW, and editing all project makefiles and all standard makefiles to use
these macros: 'make' and 'make clean' appear to work a lot better. Watch out
for rm -[Rr]f when editing.
-------------------------------------------------------
Date: Wed 10/06/2004 at 08:04 By: 0 <None>
after investigating I found that it is because obj and Current are 'symlinks'
to actual directories. That is, they are created with $(LN_S).
well, in config.make I found that LN_S = ln -s. This is because 'ln -s' *does*
exist in msys but what it does is a 'cp -r'. This explains the error message in
windows.
the workaround i used was to replace any
'rm -f linkdir; $(LN_S) realdir linkdir'
(which fails with message: 'linkdir is a directory')
with
'$(LN_S) -f realdir linkdir'
(ln -s -f forces the remove and the copy of the new dir)
impacted files were:
rules.make
Instance/framework.make
but of course obj and Current remain useless, and i live with it.
For detailed info, follow this link:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=10577>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/