Hi David thanks for your suggestions
>> 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 += -lGorm > ADDITIONAL_NATIVE_LIBRARY += EOControl EOAccess EOInterface > 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.) Yes, I can see your point but personally I don't see that much difference ;-) In the first example, you need to know that there is a gdl2.palette.make file to include from that specific directory. In the second example, you need to know that you need to add -lGorm and GDL2Palette to a specific variable. So I vote for removing the makefile fragments. Good documentation with examples is probably the key thing to get people to use our libraries and be able to link them! ;-) It may be good to review the linking flags/variables, though, and I wouldn't mind being able to do something like $(GNUSTEP_MAKE_CHECK_REQUIRED_LIBRARY Renaissance) $(GNUSTEP_MAKE_CHECK_REQUIRED_LIBRARY EOControl) which would produce a clear user warning if these are not there. (just an idea) Thanks _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
