The reason I chose opensp instead of sp is simply because when I tried installing sp on Lubuntu, it gave me an error saying "Package sp has no installation candidate", although it is in the debian repos, so I don't know whats happening with that. I also picked it due to looking at the *bsd and solaris repos, and most seem to have opensp, but not sp itself.
Thank you for your time, -Chase ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On July 30, 2018 5:53 PM, Jon Trulson <j...@radscan.com> wrote: > On 07/29/2018 07:13 PM, Matthew R. Trower wrote: > > > Jon Trulson j...@radscan.com writes: > > > > > Is it better to keep the current nsgmls until we know whether all of > > > the supported platforms are working before removing it? ie: Introduce > > > support for running the system version (and not building the CDE > > > version) in one patch or patches. Then when we are ready, we can > > > remove it? > > > > I would definitely say this. At least in master, lets not commit a > > partial conversion which knowingly may break existing platforms. We > > could easily have a flag USE_INSTALLED_NSGMLS or such, and do as you > > say. > > Yes... We would need two defines then: > > #define Nsgmls nsgmls_binary_name > > like what Chase already has, but defaulting to $(NSGMLSSRC)/nsgmls (like > now) > > Then we could have another one that indicates whether an internal or an > external one should be used: > > #define HasNsgmls YES > > So, for linux (assuming they all use the same name, "nsgmls"), the entry > in linux.cf would be something like: > > #define HasNsgmls YES > #define Nsgmls nsgmls > > Eventually of course, when we are sure the OS provided nsgmls actually > works on all of our platforms, then we can remove programs/nsgmls and > the HasNsgmls define. > > > > I also see that you default Nsgmls in Imake.tmpl as /usr/bin/onsgmls . > > > Why? At least on my Ubuntu 16.04 box, you need to install the 'sp' > > > package, which provides nsgmls. The default should be just 'nsgmls', > > > without the full path included. If debian boxes are using a different > > > name for this program, then that is a problem we would need to deal > > > with as well. How do we detect and handle this case? We only have one > > > linux.cf file. What's it called on the BSD's? > > > > One option would be to handle this detection in the imake binary. Since > > we've decided to move towards autotools rather than upstream imake, I > > don't see the harm in diverging. Of course, I'm not suggesting we go > > crazy and develop complex features, but this seems the appropriate place > > for things like this (until conversion can eventually happen). > > Alternatively, we might set the binary name to an in-tree wrapper > > script, which knows about various possible programs and calls something > > appropriate depending on what it finds on the system. > > Well, I'd like to hear from Chase as to whether that is actually the > case on Debian. > > As I mentioned before, nsgmls exists on Ubuntu 16.04 after installing > the "sp" package. > > But, in the event it has different names on the same OS > (FreeBSD/Linux/etc), then I would prefer to just use a cpp generated > wrapper script, perhaps in programs/util/nsgmlswrapper or some such. > > In that case, then maybe the Nsgmls define would simply point to that. > > It could check for HasNsgmls and decide whether to look for one on the > system, or use the CDE version directly... > > > Eventually, of course, the correct place for this would be autotools. > > Definitely. > > [...] > > --------------------- > > Jon Trulson > > "Fire all weapons and open a hailing frequency for my victory yodle." > > - Zapp Brannigan > > ----------------------------------------------------------------------------------------------------- > > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > cdesktopenv-devel mailing list > cdesktopenv-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
