Menu
I'm working on a CPAN distribution that can work on Win32 and *nix. However, in order for it to work on Win32, it requires another CPAN distribution (module) that can only be installed on Win32.
The problem with this is that, by declaring that module as a dependency, it fails to install on *nix machines. But it will not be really used/required on *nix machines, only when running on Win32.
My distribution uses ExtUtils::MakeMaker and configures dependencies in the auto-generated hash %WriteMakefileArgs.
I've tried editing Makefile.PL to add or remove dependencies based on the OS running it. However, this doesn't really work for the generation of META.json and META.yml, which are generated based on the OS where I eventually execute make dist. If I run it on Windows, then the Win32-only dependencies are added to those files and break the *nix install. If I run it on *nix, then the dependencies are not added and it may break the install on Win32 when the time to test the distribution comes.
Is there a way to define different dependencies for a specific OS, in a way that applications like CPAN or CPANminus can successfully work on each OS when installing the distribution?
736
An interactive shell called cpan is also provided in the Perl core, and is the usual way of running CPAN.pm. After a short configuration process and mirror selection, it uses tools available on the user's computer to automatically download, unpack, compile, test, and install modules.
Various Perl modules are available on the Comprehensive Perl Archive Network (CPAN). These modules cover a wide range of categories such as network, CGI, XML processing, databases interfacing, etc. Creating a Perl Module. A modules name must be same as to the name of the Package and should end with . pm extension.
To install Perl modules using CPAN, you need to use the cpan command-line utility. You can either run cpan with arguments from the command-line interface, for example, to install a module (e.g Geo::IP) use the -i flag as shown.
How to Define Package Dependencies Make the directory containing your information files the current working directory. If previous versions of your package exist and you need to specify that your new package is compatible with them, create a file named compverwith your favorite text editor.
These dependency types are: A prerequisite package– meaning your package depends on the existence of another package A reverse dependency– meaning another package depends on the existence of your package Note – Use the reverse dependency type only when a package that cannot deliver a dependfile relies on your package.
Where this pattern occurs, the component of the inheriting type must have a dependency on the component containing the supertype, either directly or through a dependency hierarchy. Dependencies are identified on the basis of the inheritance patterns in IDM. Figure 2. Service dependency between components
If your application consumes any reuse services provided by SAP, you must implement the getDependencies callback to return the service dependencies of the application. The callback must return a 200 response code and a JSON file with the dependent services appName and appId, or just the xsappname.
Don't worry; you are probably already doing everything right.
Yes, the META.json will only reflect the dependencies which Makefile.PL detects on your own machine, so say you're building the distribution on Linux and uploading it to CPAN, the META.json on CPAN won't reflect the Windows dependencies.
But that's okay, because when people install the distribution, their CPAN client won't use that META.json file to install dependencies. It will re-run Makefile.PL on the end user's system, which will generate a file called MYMETA.json, which will include the Windows depenencies if they're running it on Windows, and use the dependencies from MYMETA.json instead of META.json.
What follows are details for pedantic people, which you probably don't need to worry about:
META.json includes a section called configure_requires which lists not the distribution's requirements but the requirements of Makefile.PL itself; sometimes Makefile.PL will do some complex stuff and have its own dependencies. Because these need to be installed before Makefile.PL is run, CPAN clients get the list from META.json instead of MYMETA.json; MYMETA.json doesn't exist yet."dynamic_config": 0 in META.json which tells the CPAN client that Makefile.PL isn't doing anything "clever", so it can skip running Makefile.PL, use META.json as a definitive list of dependencies, and guess where to install any included modules and scripts. Not all CPAN clients support this, so many will run Makefile.PL anyway; so you still need to include Makefile.PL. It can just make installation a slight bit faster for those clients which support it.
146
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
