GNUStep make patch take 1
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. DETAILS: * Instance/framework.make: If HAS_LN_S is no (i.e. mingw) then define a variable HEADERS_DIR_SUFFIX for the suffix /FrameworkName to go onto the public header path. Disable Versions and Current if HAS_LN_S is no. Don't create the top level symlinks if HAS_LN_S is no. If HAS_LN_S is no then create the headers dir both with and without the HEADERS_DIR_SUFFIX I added an intermediate target for internal-framework-copy-headers-target, as I was seeing the header file copy being executed n^2 times, for every file, it copied all files. Perhaps MSYS make 3.79.1 is buggy, but this fixed it. If WITH_DLL is yes, then create a def file using DLLTOOL, and then supply it to DLLWRAP. Otherwise, the objc symbols weren't getting exported properly. * Instance/subproject.make: Handle the HEADERS_DIR_SUFFIX which was passed from framework.make. Added an intermediate target for internal-subproject-copy-headers-target, for the same reason as in framework.make * Master/framework.make: If HAS_LN_S is no (i.e. mingw) then define a variable HEADERS_DIR_SUFFIX for the suffix /FrameworkName to go onto the public header path. * Master/rules.make: Had to modify the subproject rule to disable the Versions folders to match the changes in framework.make Pass HEADERS_DIR_SUFFIX to submakes * configure.ac: Declare LN_S to be cp -rp for mingw, even if you find a ln command. (Since it is probably just a wrapper around cp anyway) * rules.make: Include the Framework.framework/Headers dir instead of derived sources if we have no symlinks Added a rule to compile .rc (windows resource) files. * target.make: Pass -Wl,--enable-auto-import option to dllwrap and gcc to avoid a warning message at link time if linking directly to a dll. * which_lib.c: Mingw searches for libraries in this order: name.dll, then libname.a. Changed which_lib to search in the same order, and to look for a static import library even in dynamic mode. This fixed many problems I had with objc_d.dll vs. objc.dll. diff -u -r -w -x .svn gnustep-make-orig/Instance/framework.make gnustep-make/Instance/framework.make --- gnustep-make-orig/Instance/framework.make Thu Sep 2 11:14:21 2004 +++ gnustep-make/Instance/framework.makeTue Jul 5 12:04:07 2005 @@ -90,6 +90,12 @@ ifeq ($(MAKE_CURRENT_VERSION),) MAKE_CURRENT_VERSION = yes endif +ifeq ($(HAS_LN_S),no) + MAKE_CURRENT_VERSION = no + HEADERS_DIR_SUFFIX = /$(GNUSTEP_INSTANCE) +else + HEADERS_DIR_SUFFIX = +endif # Set VERSION from xxx_VERSION ifneq ($($(GNUSTEP_INSTANCE)_VERSION),) @@ -108,7 +114,12 @@ FRAMEWORK_DIR_NAME = $(GNUSTEP_INSTANCE).framework FRAMEWORK_DIR = $(GNUSTEP_BUILD_DIR)/$(FRAMEWORK_DIR_NAME) +# On windows where we have no symlinks, there is no good way to do the Versions +ifeq ($(HAS_LN_S),no) +FRAMEWORK_VERSION_DIR_NAME = $(FRAMEWORK_DIR_NAME) +else FRAMEWORK_VERSION_DIR_NAME = $(FRAMEWORK_DIR_NAME)/Versions/$(CURRENT_VERSION_NAME) +endif FRAMEWORK_VERSION_DIR = $(GNUSTEP_BUILD_DIR)/$(FRAMEWORK_VERSION_DIR_NAME) # This is not doing much at the moment, but at least is defining @@ -156,7 +167,7 @@ DUMMY_FRAMEWORK_CLASS_LIST = $(DERIVED_SOURCES_DIR)/$(GNUSTEP_INSTANCE)-class-list endif -FRAMEWORK_HEADER_FILES := $(addprefix $(FRAMEWORK_VERSION_DIR)/Headers/,$(HEADER_FILES)) +FRAMEWORK_HEADER_FILES := $(addprefix $(FRAMEWORK_VERSION_DIR)/Headers$(HEADERS_DIR_SUFFIX)/,$(HEADER_FILES)) ifneq ($(BUILD_DLL),yes) @@ -266,6 +277,7 @@ $(FRAMEWORK_VERSION_DIR)/Resources \ $(FRAMEWORK_RESOURCE_DIRS) \ $(UPDATE_CURRENT_SYMLINK_RULE) +ifneq ($(HAS_LN_S),no) $(ECHO_NOTHING)cd $(FRAMEWORK_DIR); \ if [ ! -h "Resources" ]; then \ rm -f Resources; \ @@ -283,23 +295,28 @@ ./$(HEADER_FILES_INSTALL_DIR); \ fi$(END_ECHO) endif +endif $(FRAMEWORK_LIBRARY_DIR): $(ECHO_CREATING)$(MKDIRS) [EMAIL PROTECTED](END_ECHO) $(FRAMEWORK_VERSION_DIR)/Headers: $(ECHO_CREATING)$(MKDIRS) [EMAIL PROTECTED](END_ECHO) +ifeq ($(HAS_LN_S),no) + $(ECHO_CREATING)$(MKDIRS) [EMAIL PROTECTED](HEADERS_DIR_SUFFIX)$(END_ECHO) +endif $(DERIVED_SOURCES_DIR): $(ECHO_CREATING)$(MKDIRS) [EMAIL PROTECTED](END_ECHO) # Need to share this code with the headers code ... but how. -$(FRAMEWORK_HEADER_FILES):: $(HEADER_FILES) +$(FRAMEWORK_HEADER_FILES): internal-framework-copy-headers-target +internal-framework-copy-headers-target: $
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. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUStep make patch take 1
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" <[EMAIL PROTECTED]>
To: "Jeremy Bettis" <[EMAIL PROTECTED]>
Cc:
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.
cvs diff -u --binary (in directory C:\Users\jeremy\gnustep-cvs\make\)
Index: configure
===
RCS file: /cvsroot/gnustep/gnustep/core/make/configure,v
retrieving revision 1.178
diff -u --binary -r1.178 configure
--- configure 10 Mar 2005 04:21:17 - 1.178
+++ configure 15 Jul 2005 17:37:01 -
@@ -2702,7 +2702,7 @@
if test "$MINGW32" = yes; then
echo "hosted on mingw32 .."
- export INSTALL=install
+ export INSTALL="install -p"
export SHELL=sh
export CC=${CC:-gcc}
export AR=${AR:-ar}
Index: configure.ac
===
RCS file: /cvsroot/gnustep/gnustep/core/make/configure.ac,v
retrieving revision 1.38
diff -u --binary -r1.38 configure.ac
--- configure.ac22 May 2005 03:20:14 - 1.38
+++ configure.ac15 Jul 2005 17:37:07 -
@@ -109,7 +109,7 @@
AC_OBJEXT
if test "$MINGW32" = yes; then
echo "hosted on mingw32 .."
- export INSTALL=install
+ export INSTALL="install -p"
export SHELL=sh
export CC=${CC:-gcc}
export AR=${AR:-ar}
Index: rules.make
Re: GNUStep make patch take 1
I changed my mind about one part: * 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. I found that --export-all-symbols is too many symbols sometimes. For normal users that don't use __declspec(dllexport) there is no problem. For weird people like me that have __declspec(dllexport) in there I can specify --export-all-symbols in my FOO_LDFLAGS variable, or I can generate a DEF file as needed. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUStep make patch take 1
Thanks Jeremy, good patch! :-) Adam is doing a release today (I think), so I didn't want to make too many changes [in case I break more than I fix ;-)]; I've committed the fix for frameworks with subprojects on mingw32 though. I'll work on the other changes after the release ... I suspect Adam will make a minor bugfix release quite soon, so those will get into the minor bugfix release. :-) Thanks! > 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. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
