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
