On Tue, 18 Sep 2012 14:06:01 -0600 (MDT), Jon Trulson wrote: > On Tue, 18 Sep 2012, Marcin Cieslak wrote: > > > On Tue, 18 Sep 2012, Jon Trulson wrote: > > > >> Though I've added a follow on patch that disables building XmPrivate.h > >> on Linux systems, where it will always fail since linux does not build > >> with motif sources symlinked into imports/ > > > > Ok, thank you. > > > > I don't think this is a Linux-specfic problem - > > I did specify MLIBSRC in the command line. > > Well, it will be a problem for anyone that does not have a built motif > src tree symlinked into imports... > > > > > Does symplinking of "openmotif-2.3.3/lib" > > in to "imports/motif/lib" work for you? > > > > I'm not sure how that would help... Perhaps you meant motif/include? > > On Linux, we build with the Motif development packages rather than a > motif source tree. The Motif devel packages do not contain the > private headers, so even symlinking motif's includes would not work. > > > What normally happens in my tree is this: > > > > $ cd $cde/includes/Xm > > $ make includes > > + cd ../../exports/include/Xm > > + rm -f XmPrivate.h > > + ln -s ../../../include/Xm/XmPrivate.h . > > > > Is XmPrivate.h being rebuilt all the time in your tree? > > > > During the last git am of your patch, followed by a make World, the > file was deleted, causing the build to fail. Probably due to the fact > that the awk script was updated, and the Imakefile makes XmPrivate.h > dependant on the awk script. > > I just disabled this altogether in Linux - though I think it should be > disabled all of the time on all systems. > > IMO, the awk script that generates XmPrivate.h should always only be > run manually when it's needed, and never automatically. The only way > it can ever work automatically is with an openmotif source tree, built > and symlinked into imports. > > That will never be the usual case on Linux, and probably most other > systems as well. I think fbsd is special in this regard since it's > all done via the ports system. > > The Imakefile should probably just be: > > #if defined(FreeBSDArchitecture) > ...<build XmPrivate.h>... > #endif > > No idea about OpenBSD/NetBSD.
Without having tested anything, this should be disabled on OpenBSD too, since I'm avoiding symlinking includes/sources altogether in my port. Though I think the right solution is to do this via a "maintainer mode" type of define. No ordinary user compiling CDE will need to generate XmPrivate.h. > When all of these various prototype issues are fixed, I do not expect > XmPrivate.h to be modified at all going forward. > > > Both gmake and BSD make don't touch XmPrivate.h > > for me in the fresh checkout. > > > > It was wiped on my first make World after applying the patch. > > -- > Jon Trulson > > The Higgs Field is what make atoms matter. > -- Tom L. > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > cdesktopenv-devel mailing list > cdesktopenv-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel > > ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
