discuss-gnustep
[Top][All Lists]
Advanced

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

Re: PSWrap problems


From: Jay McCarthy
Subject: Re: PSWrap problems
Date: 10 Dec 2001 16:53:46 -0500

On Mon, 2001-12-10 at 07:34, Nicola Pero wrote:
> hi jay - thanks for reporting your troubles - the .c and .h files were not
> removed on `make clean' - definitely a bug - I fixed it on CVS - thanks!  
> (of course, let me know if it doesn't work for you)
 upon updating cvs is see that this problem is fixed very well - and
i'll be looking in to figure out why - it was totally above me when i
attempted.

> .h files are not installed by default and I think this is correct - some
> header files are private, other ones are public - normally you don't want
> to unconditionally install all .h files for your framework - only the ones
> to be used by external parties - so if you want your pswrap-generated .h
> file to be installed, you need to list it manually in the HEADER_FILES.  
> If you don't want them to be installed, don't list them there instead - I
> think it would be a bad idea for gnustep-make to install all headers by
> default.
 This is a very reasonable argument for not have the headers be public
by default. However, simply adding the header to HEADER_FILES does not
succeed in solving the problem (at least in a framework.) This is
because the headers are copied to the .framework directory before any c
code is compiled - thus the header files are not yet generated. this can
be fixed by adding the rule that was in my previous email (reprinted
below) which lets the .h files be created as needed as well as the .c
files (if you would like the GNUmakefile which I am using that can
provided privately) -

--- Makefiles.original/rules.make       Fri Dec  7 17:44:19 2001
+++ Makefiles/rules.make        Sat Dec  8 15:36:11 2001
@@ -391,6 +391,9 @@
 %.c : %.psw
        pswrap -h $*.h -o $@ $<
 
+%.h : %.psw
+       pswrap -h $@ -o $*.c $<
+
 
 # Prevent make from trying to remove stuff like
 # libcool.library.all.subprojects thinking that it is a temporary file
( end of patch )

> thanks again for this - great bug report.
thank you for such prompt support expertise.

-- 
Jay McCarthy <jay@kenyamountain.com>




reply via email to

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