Re: test-library.make

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: test-library.make

Nicola Pero

> Does any one use test-library.make in the make package? I don't know of
> many people who use dejagnu, and I'd rather not support it if no one
> uses it.

As far as I know, only dev-libs/db/tests uses test-library.make.

Also, I don't really know if the dejagnu code in test-library.make
actually works. ;-)  I always left it untouched but never really tried it
out.  I suppose it must work.

I would be in favour of removing all the code in
Instance/test-library.make and replacing the whole file with --

#
# [Copyright notice]
#

ifeq ($(RULES_MAKE_LOADED),)
include $(GNUSTEP_MAKEFILES)/rules.make
endif

# Just inherit the build rule from library.make

include $(GNUSTEP_MAKEFILES)/Instance/library.make

internal-test_library-all_:: internal-library-all_


-- in the same way that we do with test-tool.make and
test-application.make ... that is a library that compiles exactly like a
normal library, but installation does nothing.

... and then we'd need to move the dejagnu code that we remove from
test-library.make into the GNUmakefiles in dev-libs/db/tests/, so that
those tests keep working.

I suppose this shouldn't be too difficult, except someone would need to
test that the dev-libs/db/tests/ still work after the changes ...

Thanks




_______________________________________________
Gnustep-dev mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: test-library.make

David Ayers
Nicola Pero wrote:

> ... and then we'd need to move the dejagnu code that we remove from
> test-library.make into the GNUmakefiles in dev-libs/db/tests/, so that
> those tests keep working.
>
> I suppose this shouldn't be too difficult, except someone would need to
> test that the dev-libs/db/tests/ still work after the changes ...

I believe that dev-libs/db as a whole is more or less obsolete.  I would
attempt to update and build but is seems savannah is having problems
right now.  Anyway the version I currently have checked out I had to
remove all the GNUSTEP_MAKEFILE assignments to find out that it still
depends on the old header structure.  The build dies for me with:
...
/opt/GNUstep/System/Library/Headers/gnustep/base/GCObject.h:1:2:
warning: #warning GCObject.h is now included using the path
<GNUstepBase/GCObject.h>
EOAdaptorChannel.m: In function `+[EOAdaptorChannel
dateForAttribute:year:month:day:hour:minute:second:zone:]':
EOAdaptorChannel.m:52: warning: `NSTimeZone' may not respond to
`+localTimeZone'
EOAdaptorChannel.m:52: warning: (Messages without a matching method
signature
EOAdaptorChannel.m:52: warning: will be assumed to return `id' and accept
EOAdaptorChannel.m:52: warning: `...' as arguments.)
EOAdaptorChannel.m:54: warning: `NSTimeZone' may not respond to
`+localTimeZone'
EOAdaptorChannel.m:59: warning: `NSCalendarDate' may not respond to
`-setTimeZone:'
EOAdaptorChannel.m:61: warning: `NSCalendarDate' may not respond to
`-setCalendarFormat:'
EOAdaptorChannel.m: In function `-[EOAdaptorChannel
initWithAdaptorContext:]':
EOAdaptorChannel.m:68: error: `TRY' undeclared (first use in this function)
EOAdaptorChannel.m:68: error: (Each undeclared identifier is reported
only once
EOAdaptorChannel.m:68: error: for each function it appears in.)
EOAdaptorChannel.m:68: error: parse error before '{' token
EOAdaptorChannel.m: At top level:
EOAdaptorChannel.m:71: error: parse error before "CATCH"
EOAdaptorChannel.m:71: warning: return type defaults to `int'
EOAdaptorChannel.m: In function `CATCH':
EOAdaptorChannel.m:71: error: parameter name omitted
EOAdaptorChannel.m:72: error: `self' undeclared (first use in this function)
EOAdaptorChannel.m:73: error: `RERAISE' undeclared (first use in this
function)
EOAdaptorChannel.m: At top level:
EOAdaptorChannel.m:76: error: parse error before "return"
EOAdaptorChannel.m: In function `-[EOAdaptorChannel insertRow:forEntity:]':
EOAdaptorChannel.m:111: error: `InvalidArgumentException' undeclared
(first use in this function)
EOAdaptorChannel.m: In function `-[EOAdaptorChannel
fetchAttributes:withZone:]':
EOAdaptorChannel.m:301: warning: implicit declaration of function `THROW'
make[2]: *** [shared_debug_obj/EOAdaptorChannel.o] Error 1
make[1]: *** [libgnustep-db.all.library.variables] Error 2
make[1]: Leaving directory `/usr/local/src/cvs/gnustep/dev-libs/db/eoaccess'
make: *** [internal-all] Error 2

I would be in favor of removing dev-libs/db (well possibly only the
files leaving the directories so that the cvs history is maintained.)

Cheers,
David



_______________________________________________
Gnustep-dev mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/gnustep-dev