Re: GNUStep make patch take 1

[Jeremy Bettis]

I have the vague feeling that I should be sending these to the patch tracker 
on savannah, but here we are:

Thanks for the windows changes in CVS, I have a few more things that I 
changed to make things go:  This patch is relative to CVS as of about 20 
minutes ago.

* configure: Need to use install -p instead of install, so that make doesn't 
rebuild frameworks everytime due to header copies.
* configure.ac: Same change
* rules.make: Don't create the obj symlink (we have no symlinks and it 
leaves a useless empty dir)
* target.make: add -Wl,--export-all-symbols to SHARED_LIB_LINK_CMD, so that 
ld will export all symbols even if the code uses __declspec(dllexport) 
extern. See 
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gnu-linker/win32.html
for more info.  Also add -Wl,--enable-auto-import to ADDITIONAL_LDFLAGS to 
shut up a linker warning.
* which_lib.c: when searching for _d _p stuff, on windows look for 
FOO_d.dll, then libFOO_d.dll.a, then libFOO_d.a, since that is the same 
sequence that ld will use when linking.
* Instance/framework.make: I changed the build-headers code to be faster, 
because I have
209 public headers in my framework, and the old makefile was doing 209*209 
copies.  Changed the $(FRAMEWORK_FILE) target to NOT $(LN_S) the files to 
the framework dir unless the link actually succeeded.
* Instance/subproject.make: Make build-headers faster.
* Master/rules.make: Changed subproject to reflect changes to framework.make 
wrt Versions dir.


----- Original Message ----- 
From: "Nicola Pero" <address@hidden>
To: "Jeremy Bettis" <address@hidden>
Cc: <address@hidden>
Sent: Friday, July 15, 2005 6:06 AM
Subject: Re: GNUStep make patch take 1


> Thanks Jeremy!
>
> I spent quite some time on this, and I committed the results.
>
> I need to restart yet a last time Windows to check that all is actually
> OK, but pseudo-frameworks are supposed to be working for me on Mingw ...
>
> ... I also moved them to use the new building system used by libraries.
>
> A few things are done differently, please have a look at the gnustep-make
> CVS and see if they work for you! ;-)
>
> I didn't test subprojects though (need to test those too!).
>
> A last thing is maybe we want to remove the top-level xxx.framework/xxx
> file, which currently is just a copy of the .dll.
>
> Thanks
>
>
> PS: I must say the fact that there are no symlinks means we are
> effectively copying the framework .dll, .dll.a and headers in the standard
> install locations for libraries.  This doubles the framework installation
> size with no actual benefit (compared to a library or a bundle, whatever
> the framework is used as).
>
> So I sort of consider this as a help in porting quickly, for an 'advanced'
> port to Windows I would still recommend using libraries and bundles only
> which are much more efficient in disk space usage (if you want to build a
> standalone Windows application, this might be quite important).
>
> Problem is, I can't really think of a workaround that works well.  We
> can't delete the .dll from the xxx.framework else you wouldn't be able to
> load it as a bundle.  We can't delete the .dll from the tool path else you
> wouldn't be able to link to it as a library.  So we end up with having
> both, but that doubles the size. :-(
>
> Anyway, it's good we have this
>
> Thanks for your contribution! :-)
>
>
>
> > Relative to GNUStep make 1.10.0
> >
> > I will try to explain what I have done:
> >
> > HIGH LEVEL:
> >     Some little mingw tweaks, dlls etc.
> >     Don't do anything that requires symlinks on mingw.  I.e. Framework 
> > Versions and Current folders, and framework headers in derived_sources.
> >     Mingw will link directly against dlls before using an import library. 
> > I had to change target.make and which_lib.c to be aware of this.

make-diff.txt
Description: Text document