Maybe it wasn't the correct word, but in Imake, you can implement things like 
"LinkSourceFile()" which has Imake replace that and it's argument with the 
correct implementation of a symlink build instruction on make, autotools 
doesn't have that functionality as far as I've read.


Thank you for your time,
-Chase

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, January 21, 2019 6:16 PM, Jon Trulson <j...@radscan.com> wrote:

> On 1/21/19 4:22 PM, Chase wrote:
>
> > I did see this, but doesn't the preprocessor define instances of v_io_buf 
> > as it's ptr version? Or is that only
>
> Only if if C_API is defined. Otherwise v_io_buf is used.
>
> <within that file? And what about the references to dtxlate stuff from
> the exported version of DtMmdb? I have no idea where to start there.
> C_API is defined during compilation (all I did was move DtMmdb to lib
> and disable building of mmdb.
>
> I don't know as I've never looked into the mmdb stuff.
>
> It's clear there are things going on that you do not quite understand
> yet -- for example why there are two mmdb libs where one symlinks to
> another.
>
> You should figure out why that was done first before changing anything...
>
> Maybe they are built with different defines so that the lib exports
> different behavior to different software components for some reason.
> C_API is a clue, there may be more - read the Imakefiles and look at the
> options passed when building them.
>
> You will have to figure out how this is all being built and used now
> before you can re-implement it properly...
>
> Also, I was puzzled by this comment earlier:
>
> > > > would take me a long time to write makefile.ams for due to the fact that
> > > > as far as I can tell, automake doesn't have an easy way to implement
> > > > macros, and thus I would have to write a plain Makefile direction for
>
> What do you mean that automake doesn't have an easy way to make macros?
> What macros?
>
> -jon
>
> > Thank you for your time,
> > -Chase
> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > On Monday, January 21, 2019 4:24 PM, Jon Trulson j...@radscan.com wrote:
> >
> > > On 1/21/19 2:07 PM, Chase via cdesktopenv-devel wrote:
> > >
> > > > Hi all,
> > > > The further and further I delve into the document building system in
> > > > CDE, the more of a trainwreck I see that it is.
> > >
> > > :)
> > >
> > > > I have been working on the autotools port, and one point of interest I
> > > > am running into continuously is the issue of downsizing duplicate code.
> > > > I have successfully done this with the replacement of nsgmls, however
> > > > due to the in progress replacement of the sgml docs with xml docs, this
> > > > patch was rejected. Matthew said he would do this, however due to real
> > > > life obligations and the size of the task, I don't believe that this
> > > > will be done soon. No matter, nsgmls was simple enough to make a
> > > > makefile.am for.
> > >
> > > Good - I think as you get this stuff building, it would be unwise to
> > > make other changes that affect behavior.... We can address that stuff 
> > > later.
> > >
> > > > However, what isn't simple is the make file for dtinfo/mmdb. To make it
> > > > short, this entire directory is just simlinks to dtinfo/DtMmdb, this
> > > > would take me a long time to write makefile.ams for due to the fact that
> > > > as far as I can tell, automake doesn't have an easy way to implement
> > > > macros, and thus I would have to write a plain Makefile direction for
> > > > each of the symlinked files. I tried to implement a merge of dtinfo/mmdb
> > > > and dtinfo/DtMmdb, but I have hit these two linker errors that I am
> > > > stumped on (log file attached). Could anyone help me with this?
> > >
> > > So do you know why these are two separate dirs for building? I don't,
> > > but usually there is a reason, like some sort of translation of symbols
> > > and the like.
> > > At any rate, if you look at programs/dtinfo/DtMmdb/object/pstring.h you
> > > will see that this member variable is not available if everything is
> > > built with C_API defined, which C_API should always be defined.
> > > So I am guessing that when /programs/dtinfo/dtinfo/src/Marks/Mark_mmdb.C
> > > was compiled, C_API was not defined as it should be. This would then
> > > cause pstring::v_io_buf_ptr to be used instead, which you should see if
> > > you run 'nm' on the programs/dtinfo/DtMmdb/libDtMmdb.so.2.1 library.
> > >
> > > > TLDR; Need help with optimization patch, can provide WIP patch if needed
> > >
> > > TLDR; ensure C_API is defined when Marks/*.C is compiled...?
> > > -jon
> > >
> > > > Thank you for your time,
> > > > -Chase
> > > > cdesktopenv-devel mailing list
> > > > cdesktopenv-devel@lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
> > >
> > > --
> > > Jon Trulson
> > > "The Party told you to reject the evidence of your eyes and ears.
> > > It was their final, most essential command."
> > > -- 1984
> > > cdesktopenv-devel mailing list
> > > cdesktopenv-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
>
> --
>
> Jon Trulson
>
> "The Party told you to reject the evidence of your eyes and ears.
> It was their final, most essential command."
>
> -- 1984




_______________________________________________
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Reply via email to