The number of sub-packages I want to create are so many (about 300 over).
I think.. to make the sub-package, the files should be installed (%install) early.
So I installed whole files to some specific directories.
Now I want to pack the file for each directory name.
in summaries,
Is it possible to repeat rpm macros? (ex, %package %description %files)
If it's possible, what should I use to repeat? (ex for ??)
As I know, to use %files macro, the real files should be installed previously. then where should I write the codes?
Natively, no there isn't. You'll have to use an external templating language like jinja2 to create the spec file on-the-fly.
That being said, having 300 subpackages is going to be an absolute nightmare for both your CM folks and for your users. You might want to ask another question explaining the use case to see if there are better alternatives.
Related
When migrating large code bases to nnbd, it would be helpful if we could opt entire local packages in/out of NNBD. For example, I may want to migrate some of my leaf nodes first, like /lib/helper_widgets/* before moving onto the higher-order views.
Currently dart supports this on a per file basis using // #dart=2.12 which is fairly tedious if your package has many files.
I was hoping I could do this with lib and part of, but this just gives me a compile error, to add a header to each file.
[Edit] A pragmatic solution here is to run something like find . -name "*.dart" | xargs sed -i "1s/^/\/\/ #dart=2.9\n/" on your project. That will put the 2.9 import in every file. At that pt, you can use find/replace to just turn on entire sub-directories of your /lib code.
It's gonna be either per file, or with the pubspec.yaml. The pubspec method will change the entire package. If you use dart migrate, that's one of the steps it performs. Then be sure to dart pub upgrade, because a different set of dependencies will then be available.
I am trying to install GeneMark-ES but when trying to run as specified in the documentation several PERL modules are missing. I have tried to point to all the necessary files by defining PERL5LIB variable.
However, I have come across several files which are installed but there is more than one file in various directories. Not only that, each file has different file sizes.
Why is that happening? What file should I use?
Here is a GUI search for files named Simple.pm
Those Simple.pm files are module files, and each one is for a different "distribution".
For example, the one highlighted in the image is for Locale::Maketext::Simple. Simple.pm is the actual module file itself. The first one in the image is for Bio::Location::Simple etc. The Bio/Location part of the path signifies the actual name of the distribution as you can see.
The installation instructions should outline exactly which distributions it requires. You don't just use the Simple.pm file directly.
You need to read Perl Modules from the documentation to understand how Perl uses module names
After absorbing that, you will see that there are in reality only three different library locations which together contain ten module files that end with Simple.pm
/home/pollo/perl5/lib/perl5
/usr/share/perl5/core_perl
/usr/share/perl5/vendor_perl
Nowhere is there anything that looks like GeneMark-ES, but it seems unlikely that it would end with ::Simple if it were even there
Please open a new question and describe your experience trying to install the module that you require instead of offering misleading and irrelevant facts
there is an --exclude option but that to exclude the directories/files. I work on a big project and want to only include the directories that has source code and not build stuff.
How to do that? What should I include in my .ctags file?
I use:
find FILES | ctags -L -
where FILES is the appropriate arguments to make find return only the files I want to index.
Exuberant Ctags (5.8) is now old and unmaintained, though. It still works for me, so I've not switched; but the last time I checked "Universal Ctags" appeared to be the way forwards, so I would suggest starting there:
https://ctags.io
https://github.com/universal-ctags/ctags
n.b. I experienced a curious bug with Exuberant Ctags 5.8 whereby find . resulted in some corrupted tag entries, but find * did not; so you might want to use the latter if using this approach. I didn't need to index any dot files at the root level, so I'm not sure offhand what happens for .* -- I don't think I tried it. Absolute paths were also fine, but then the TAGS file isn't portable. Potentially not an issue in the newer fork.
I'm trying to use a perl program on a Windows HTCondor computing cluster. The way HTCondor on windows works is it copies all dependencies into a temporary directory (used as a chroot of sorts) and then it deletes the directory after the specified outputs are moved to a designated place.
If I take only perl.exe and perl514.dll and make a job like this: perl -e "print qq/hello\n/" and tell the cluster to run it 200 times, then each replication winds up taking about 15 seconds, which is acceptable overhead. That's almost all time spent repeatedly copying the files over the network and then deleting them. echo_hello.bat run 200 times takes more like two seconds per replication.
The problem I have is that when I try to use my full blown perl distribution of 55MB and 2,289 files, a single "hello" rep takes something like four minutes of copying and deleting, which is unacceptable. When I try to do many runs the disks on the machines grind to a halt trying to concurrently handle all the file operations across all the reps, so it doesn't work at all. I don't know how long it might take to eventually finish because I gave up after half an hour and no jobs had finished.
I figured PAR::Packer might fix the issue, but nope. I tried print_hello.exe created like this: pp -o print_hello.exe -e "print qq/hello\n/". It still makes things grind to a halt, apparently by swamping the filesystem. I think a PAR::Packer executable makes a ton of temporary files as it pulls out files it needs from the archive. I think the windows file system totally chokes when there are a bunch of concurrent small file operations.
So how can I go about cutting down the perl I built to something like 6MB and a dozen files? I'm really only using a tiny number of core modules and don't need most of the crap in bin and lib, but I have no idea how to proceed ripping out stuff in a sane way.
Is there an automated way to strip away un-needed files and modules?
I know TCL has a bunch of facilities for packing files into a single uncompressed archive that can then be accessed through a "virtual filesystem" without expanding the file. Is there some way to do this with perl itself sort of like with PAR? The problem is PAR compresses everything and then has to extract to temporary files, rather than directly work through a virtual filesystem layer. (If I understand correctly.)
My usage of perl is actually as a scripting layer. It's embedded in a simulation. So I'm really running my_simulation.exe which depends on per514.dll, but you get the idea. I also cannot realistically do anything to the HTCondor cluster other than use it. So there's no need to think outside the box on what I should be using instead of perl and what I could administratively tweak in Windows and HTCondor, thanks.
You can use Module::ScanDeps to get list of actual dependencies of your perl. It was terrible, that it took significant amount of time, when PAR::Packer unpacked the whole application, so I decided to build the executable by myself.
Here is my ready to use script which gathers perl dependencies into some directory; it might be useful for you to reduce the number of perl-modules, e.g. by manually removing some dependencies after copying.
In theory (I have never tried that), the next your step could be merge all pure-perl dependencies into single file (like deps.pm); although it might be non-trivial due to perl's autoload magic and some other tricks.
You can list the modules that are needed by your program using the very nice ListDependencies module
To my knowledge it isn't downloadable anywhere, but it is simple to copy and paste into your own ListDependencies.pm file
You should read the POD documentation within the module for usage instructions
I am currently creating a Perl module for in house use. I used ExtUtils::ModuleMaker to generate a build script and skeleton for my Perl module. I would like to include .ini config files that my core modules need to run properly. Where do I put these files so they are installed with my module? What path do I need to use to access these config files across the main and sub modules?
P.S. this is the directory frame:
|-lib
|---Main.pm
|---Main
|-----subModule1.pm
|-----subModule2.pm
|-----subModule3.pm
|-scripts
|-t
If you are using Module::Install, you can use Module::Install::Share and File::ShareDir.
If you are using Module::Build, you may want to use its config_data tool and and a *::ConfigData module.
Taking a look at the generated Makefile, I would bet the better place to put it is under lib/Main and then you can direct your module to look at ~/.modulerc first, then PERLLIB/Main/modulerc.ini or something like that.
You could also embed the defaults in your module in a way that, in absence of ~/.modulerc, the module works using the default data.
To find the home directory, see File::HomeDir. You'll not want to use ~ (since that's a shell thing anyway).
I would suggest having your module work without the rc file as much as possible. If it doesn't exist, the code should fall back to defaults. This should be true, too, even if the file exists, but a particular flag is missing - it should fall back to the default, too.
You may want to look at Config::Any while you're at it. No point reinventing that wheel.