Re: Auxiliary makefile fragements

[Nicola Pero]

It's not an easy issue and I suggest we think carefully :-)

I'm not a fan of the auxiliary makefile fragments.  But I generally  
agree with you that we need
to review these issues, and also I like your idea of being able to  
check if a library is available
or not - mostly to print a user-friendly message to the user about the  
problem :-)

I'm not a fan of auxiliary makefile fragments mostly because gnustep- 
make already provides
a highly standardized setup.  You don't need to mess around that much  
with include/linker flags
to use a GNUstep library.  Eg, if you want to use libPerformance from  
dev-libs when compiling
your application HelloWorldTest, you just need to do

HelloWorldTest_GUI_LIBS += -lPerformance

gnustep-make will create all the include/linker flags so that all works.

We may want to review the names of link flags etc, but I can't think  
how you
can make using libPerformance much easier than this.

Including a makefile fragment sounds more complicated than just adding  
the
-lPerformance flag yourself. ;-)

Makefile fragments have some disadvantages, at least as they are now:

 * they usually link everything against the libraries; you can't  
easily control what
is linked and what not ;-)

 * you can no longer install your library into the USER domain  
without touching
the system stuff.  Normally, you can install a library into USER, and  
easily
use it as above by adding -lxxx.  If the library is using a makefile  
fragment installed
into GNUSTEP_MAKEFILES/Auxiliary instead, this is no longer possible -  
since
you must install the makefile fragment to use the library (installing  
it in USER
does not work). :-(

So, I would suggest that we do not use auxiliary makefile fragments  
unless we're
forced to.  I mean, yes, Renaissance could install a makefile fragment  
that does

ADDITIONAL_NATIVE_LIBS += Renaissance

so you can include that makefile fragment instead of writing this line,
but I fail to see where the advantage is - compared to just writing that
line in your GNUmakefile. ;-)


Installing an auxliary makefile fragment can make sense if you need  
special
flags to link a certain library - I can't think of much but there must  
be cases
where you may need some special flags to link something.  In that case,
we should probably agree on some standard conventions, eg,

Renaissance_COMPILE_FLAGS = -fasm-blocks
Renaissance_LINK_FLAGS = -Wl,-some-linker-flag

We could also think of having a standard gnustep-make "function" or API
to check if a library is installed.  Hmmm.

Thanks



> I can't seem to find the thread that prompted this so sorry if whoever
> posted the issue not subscribed, but I think we should probably decide
> on how to handle this in general on the developer list.
>
> $(GNUSTEP_MAKEFILES)/Auxiliary/
>
> What are the semantics of makefile fragments installed here?
>
> - should all library/framework/bundle packages install fragment that a
> user of this l/f/b can simply -include and forget about the exact  
> flags
> for linking?
>
> - can this be used to determine whether a package is installed or not?
>
> If so... may I request GormLib/ and Renaisance install such  
> fragemants?
> (hmm and on OS X can I simply assume that the InterfaceBuilder  
> Framework
> exists?)
>
> I'm personally still not swayed in either direction.  Yet I've bloated
> GDL2 with the fragments I think could seem useful for users.  But I
> remain unconvinced that this is the correct approach.  (Just like I
> couldn't convince myself of the usefulness to include
> Additional/gui.make and override that within -make via NEEDS_GUI=no)
>
> But either way, I think we should either consistently all install such
> fragments or we should all refrain from doing it.
>
> What do you folks think?
>
> Cheers,
> David
>
>
>
>
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnustep-dev