[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Singular library include directories



Hi Doug,

On 15/03/15 04:36, Doug Torrance wrote:
> Hello!
> 
> As I mentioned in my earlier emails regarding MPIR, I'm currently
> working on packaging Macaulay2, which also depends on some of the
> libraries from Singular.
> 
> I was pleased to see that Singular was recently packaged by Jerome
> and is sitting in NEW.  I checked it out from git, built and
> installed the packages, and then tried building Macaulay2.
> 
> However, I ran into an issue.  The Debian Singular package installs
> all the header files in subdirectories of /usr/include/singular, as
> opposed to upstream, which installs them in /usr/include.

True. The reason is that `factory' is rather a generic name, so to avoid
any conflict and make things clear, the singular material is put in singular
folders. This may not be an issue provided that the autotools machinery is set
correctly by the involved parties. As concerns singular, the pkg-config(1)
metainformation files are meant to be set up according, if not this is a bug
that must be fixed (please fill a bugreport if necessary). Please also note
that the lib<WHATEVER>-config are not installed because they are redundant
with the pkg-config(1) metainformation files, less efficient then them,
and that they pollute the bin folder. Furthermore, pkg-config(1) comes
with ready to use autoconf macro (see AUTOCONF MACRO in pkg-config(1) for details).
Personally, I think that lib<WHATEVER>-config stuff is now an obsolete approach,
and that they should be wiped out from the upstream source itself sooner or later.



  However,
> the header files themselves have not been patched to account for
> this.  For example, /usr/include/singular/factory/factory.h has the
> line
> 
> #include <factory/factoryconf.h>.
> 
> However, I believe it should be
> 
> #include <singular/factory/factoryconf.h>.

This may be not necessary provided that the include path is set properly:
this set up is meant to be done through the autotools machinery, see above.
If it does work within a properly setup autotols scheme, it is a issue
that deserves a bugreport.


> 
> Part of me questions whether moving everything into the 'singular'
> subdirectory is even necessary.  According to the patch descriptions,
> this change was made to avoid "possible collision". Do we know if any
> such collisions actually exist?

Of course, nobody want that such collisions exist, hence the moving.
Once again, factory is a generic name that can be used in a lot of
context as, for example, factory configuration: I do control the singular
packaging and its set, but I will not control other `factory' material
coming from any other past, present or future software. This conflict issue
is common in Debian: SLURM (slurm-llnl or slurm), surf (to surf on the web or to plot surfaces),
...


  It also makes it more complicated

I am disagree.

> for packaging reverse dependencies (like Macaulay2).

If autotools is properly employed, it be should transparent;
it may concerns the involved configure.ac and Makefile.am)
 

> 
> Whatever is decided, I'm happy to help with the work.
> 

I will be glad to help for the autotools part.


> Thanks! Doug
> 
> 

Thanks, Jerome (alias calculus | quatermaster _at_ rezozer _dot_ not)


-- 
Jerome BENOIT, Ph.D. | jgmbenoit-at+rezozer*dot_net
http://www.rezozer.net/


Reply to: