[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNUStep make patch take 1

From: Nicola Pero
Subject: Re: GNUStep make patch take 1
Date: Fri, 15 Jul 2005 12:06:50 +0100 (BST)

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.


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:
>     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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]