[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: two bugs while building back on mingw
From: |
Nicola Pero |
Subject: |
Re: two bugs while building back on mingw |
Date: |
Fri, 12 Apr 2002 08:58:09 +0100 (BST) |
> 2. As the new backend works with subproject these must now be able to
> correctly set set the XXX_ISDLL flags as well. Currently we have this
> correct for applications, libraries and bundles, but not for
> subprojects. Before adding a new workaround I would prefer a general
> solution that would work with all the different project types.
> Perhaps it would be sufficient to extract that code into a shared file,
> set one variable, e.g. ALL_USED_LIBS and than include that shared file.
Hmmm.
Ok - thanks - the things to do are starting to become more clear ... and
so the problems :-)
If you create a bundle, currently you don't have to specify if it's a gui
or a base bundle. If you create a subproject, you just compile some
files, and link later on in the main project. So you don't have to
specify the libraries both in the subproject and in the main project.
If we make this change, to compile a subproject on Windows, you have to
specify all libraries twice, both in the main project and in the
subproject. If you have many subprojects, it can be very annoying.
Can I ask one question then - is 'BUILD_libgnustep_gui_DLL' and
'libgnustep_gui_DLL' a general standard for building unix stuff on
Windows, or is it more or less a gnustep-only trick ?
Because if it's a gnustep-only trick, we could modify it in the following
way:
#if GNUSTEP_WITH_DLL
#if BUILD_libgnustep_gui_DLL
# define APPKIT_EXPORT __declspec(dllexport)
# define APPKIT_DECLARE __declspec(dllexport)
#else
# define APPKIT_EXPORT extern __declspec(dllimport)
# define APPKIT_DECLARE __declspec(dllimport)
#endif
#else # GNUSTEP_WITH[OUT]_DLL
# define APPKIT_EXPORT extern
# define APPKIT_DECLARE
#endif
Then, we always define
-DGNUSTEP_WITH_DLL
when we compile with DLL on Windows. That automatically dllimports
everything you #include, except when -DBUILD_libgnustep_gui_DLL is defined
(which we do when we compile gnustep-gui).
It's better because we don't need to define anything else (ie, we can drop
all clumsy code trying to build -Dlibgnustep_gui_DLL each time you use
gnustep-gui): if you include AppKit/AppKit.h, all stuff which should be
dll_imported is automatically dll_imported, without you having to manually
specify that you are using gnustep-gui.
This is a lot better - because then you would no longer need to specify
all libraries you are using, and in a subproject whenever you include a
header, all stuff in the header is automatically dll_imported.
Makes sense ?
Otherwise, we need to make a separation between libraries which are
specified only so that dll_import is properly setup (these libraries would
be specified in a ADDITIONAL_DLL_LIBS or something), and libraries which
are specified so that both dll_import is setup, and they are also linked
in.
Let me know if I'm missing something.