Re: Auxiliary makefile fragements

[David Ayers]

[added Peter as CC: since his request prompted this discussion]
http://lists.gnu.org/archive/html/bug-gnustep/2009-01/msg00191.html

Am Dienstag, den 17.02.2009, 23:46 +0000 schrieb Nicola Pero:
> It's not an easy issue and I suggest we think carefully :-)

Indeed.

> 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 ;-)
> 

Well, if you need the control, you could always refrain from using the
fragment... but I also don't think it's a good idea many slightly
different options each with it's own quirks and pitfalls. 

>   * 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). :-(

This sounds like a real issue!

> 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. ;-)

I think the advantage from a user perspective is that if you want to
write a palette that builds on GDL2 palette and the EOModeller
framework, it would be neat to simply:

include $(GNUSTEP_MAKEFILES)/Auxiliary/gdl2.palette.make
include $(GNUSTEP_MAKEFILES)/Auxiliary/gdl2.EOModeler.make

instead of knowing that you need to add:
ADDITIONAL_LIBRARY += -lGrom
ADDITIONAL_NATIVE_LIBRARY += EOControl EOAccess EOInterace
ADDITIONAL_NATIVE_LIBRARY += EOModeler GDL2Palette

(But actually, you still may need to add/set PALETTE_LIBS so indeed you
need to know more precisely what you need to link.)

> 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.

Well either way... I'd like to come to decision.  If we want these
convenience fragments, then I'd like to include Gorm and Renaissance
fragments from within the GDL2 fragments (and applications).  Otherwise
I'd like to remove the fragments that add the linker flags.

> > 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
>