bugGNUstep - Bugs: bug #10577, Fix symlinks for use on Windows

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #10577: Fix symlinks for use on Windows

Submitted by:  Adam Fedor <fedor>
Submitted on:  Mon 04 Oct 2004 10:59:25 PM UTC  
 
Category: MakefilesSeverity: 2 - Minor
Item Group: BugStatus: Fixed
Privacy: PublicAssigned to: Nicola Pero <nico>
Open/Closed: Closed

Fri 05 Nov 2004 06:04:09 PM UTC, comment #4:

I got an email from Patrick Middleton saying "Works for me; WinXP + 1.10.1 development installer.".

So I'm closing the bug.

Thanks

Nicola Pero <nico>
Project MemberIn charge of this item.
Thu 04 Nov 2004 08:47:34 AM UTC, comment #3:

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!

Nicola Pero <nico>
Project MemberIn charge of this item.
Wed 03 Nov 2004 11:49:35 AM UTC, comment #2:

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.

Patrick Middleton <patrickx>
Wed 06 Oct 2004 08:04:29 AM UTC, comment #1:

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.

Anonymous
Mon 04 Oct 2004 10:59:25 PM UTC, original submission:

From: andre levy <gsalevy@almonde.com>
Date: September 16, 2004 10:10:04 AM MDT
To: -unavailable-
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...

Adam Fedor <fedor>
Project Administrator

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

Do you think this task is very important?
If so, you can click here to add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.

 

Please enter the title of George Orwell's famous dystopian book (it's a date):

 

 

Follow 4 latest changes.

Date Changed By Updated Field Previous Value => Replaced By
Fri 05 Nov 2004 06:04:09 PM UTCnicoStatusNone=>Fixed
  Open/ClosedOpen=>Closed
Thu 04 Nov 2004 08:47:34 AM UTCnicoCategoryBase/Foundation=>Makefiles
  Assigned tofedor=>nico

Back to the top


Powered by Savane 3.1-cleanup1