On Fri, Jun 01, 2018 at 02:40:33PM +0000, Liam Goodacre wrote: > I've got it to work, but when I generate the package it doesn't identify the > platform, giving me something like "context[v0.4]--.dek". I guessed that this > was because the externals I'm using are all in sub-folders, so I tried > copying one across to the main folder. Sure enough, the package now > identifies the platform correctly, but I'm not sure what the best course of > action is from here. Should I:
the main obstacle here is that this is not really the common use-case for which deken cmdline is optimized (which is: packaging a single library, without internal dependencies). i think that the tool should cover the most common use cases, but there is no need to support edge cases (the difficulty is obviously in drawing the line). > 1. zip the package with the extra external, then delete it once the > compression is done (but this would probably invalidate the checksum?) well, if the checksum (and/or gpg signature) are missing and you are using `deken upload` for uploading they will be automatically (re)generated. (however, i was thinking about introducing "--gpg=no" and "--hash=no" args to prevent this (also for packaging). > 2. zip the package without the extra external, then rename it manually not sure i totally understand what you mean by this, but it sounds brittle. > 3. something else? probably a "--recursive" (or similar) flag to indicate that subdirectories should be searched recursively would help (please open a ticket in the issue tracker, if you agree). it was a conscious decision to *not* do recursive searches by default, i don't think i want to change that. mgfdsar IOhannes > > Thanks, > > Liam > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
