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. > 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. Eventually, of course, the correct place for this would be autotools. -mrt ------------------------------------------------------------------------------ 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
