http://qs321.pair.com?node_id=631729


in reply to Free thoughts about Perl development

apt_get works under either Fedora or Debian is an rpm binary installation method.

But Mac OSX does not support apt or rpm as far as I am aware. It is therefore easiest if every dependency is achieved via a tarball source installation that uses make to compile and install from sources.

Make sure that each component uses the right basic library root i.e. if OSX has everything preinstalled in /usr/local/lib then before doing a make install of a component, check that it's going to go to the right place. But generally, if all the products are done by tarball then they tend to agree with each other just as if everything is done with apt and rpm they will also agree with each other. The only proviso is that it also has to agree with how the libraries are preinstalled for Mac OSX.

Windows doesn't have a consistent library architecture - in spite of some common directories for DLLs there just isn't the adherence in general so I'd be inclined to reject Windows as infeasible.

__________________________________________________________________________________

^M Free your mind!

  • Comment on Re: Free thoughts about Perl development

Replies are listed 'Best First'.
Re^2: Free thoughts about Perl development
by Corion (Patriarch) on Aug 10, 2007 at 09:12 UTC

    Windows has a very consistent way of placing DLLs - just place them in the same directory as your executable program, in this case, perl.exe.

      The OP has multiple interdependent installations - to get results he therefore needs a common library architecture.

      So your comment about DLLs being local to a software component SUPPORTS my somewhat tentative accusation that Windows doesn't have it.

      Update: To clarify, it might be theoretically possible to put shortcuts to or copies of all relevant DLLS in different places - but what is theoretically possible isn't nearly as strong as saying something is "feasible", especially if you think through properly all the nasty obstacles that could appear such as an undocumented DLL filename not being present for a component. The OPs successful effort succeeded in an rpm environment that manages dependencies properly - it should ring the right alarm bells if you consider the implication that it didn't work in environments where dependencies were not managed.

      __________________________________________________________________________________

      ^M Free your mind!