we call Mac PackageMaker from an Ant script, to build our product installation package.
I would like to pass a parameter 'productConfiguration', that will direct the package to include or exclude certain components, e.g. in order to create a smaller Trial version package.
What is the correct way to achieve that?
Notes:
In Windows we use InstallShield's Features, Conditions, Release Flags, Configuration Flags.
Are there similar concepts in PackageMaker?)
Where is the documentation of pkmkdoc spec 1.12?
The only way I can think of, is to generate [some of] the xml files inside the install.pmdoc smart folder, using templates. But it looks very inelegant to me.
Packagemaker doesn't contain a lot of sophisticated features for things like this. I would suggest tweaking the ant script by creating a separate build target that builds the trial installer. This target can customize both the files included and the PackageMaker parameters.
Related
I have a source tree that can build two different projects from the same source. You call make A or make B, and the code is affected by ifdefs and similar using preprocessor variables to make two versions of the output. I'm looking to make dpkgs for these, and can make one fine, but am unsure of a good way to do this.
Currently I run dpkg-buildpackage, and I get A.deb or similar. Is there a way to do dpkg-buildpackage -target B so that it would then build a debian package for that project?
Things such as Creating multiple packages with dpkg-buildpackage seem to refer to having separate source code for the separate projects, which is not the case here.
I am in control of the source code so can make changes there.
Thanks.
You can set up one rules file to build two separate Debian packages at the same time. But if they are unrelated, this is an abuse of the Debian packaging procedure. It's designed for building multiple related Debian binary packages from a single source.
We have a product with more than 100 'pieces' most of which are optional 'plug-ins'. We would like a non-programmer to be able to make a "customized" installer on a per-customer/sale basis. Our ideal would be simply a single executable/msi with a folder structure from which files/folders could be deleted, then when run the installer would simply not offer features corresponding to the deleted bits.
A separate, but similar issue is that the developers of these plug-ins are not installation experts and we would prefer not to have to edit shared installer source to add/remove one from our build-set. We've been using the "synchronized folders" feature of Advanced Installer for this, but we would like a separately selectable feature for each plug-in.
Is there an installer tool-chain that can support such(or similar) behavior?
If so does anyone have tips on how to actually implement it using said tool?
I created such a tool stack at my last job. We did product line development with dozens of service families, hundreds of features, thousands of merge modules and tens of thousands of files in a typical installer.
Each merge module was authored using IsWiX and compiled using WiX. We then used WiX XML as an input to our build automation system to generate InstallShield installers. A service family would have an XML file to describe it's portion of the feature tree and it would all get emitted into an empty InstallShield project.
Finally a product XML file would describe the INSTALLDIR, UpgradeCode and other meta along with which features to consume. We built dozens and dozens of installers off this common base code.
It would take days to explain everything but that gives you the idea. For a simpler environment you could create a UI to generate WiX code and then compile it into an MSI.
But I don't know that I'd ever give this to a non-programmer. Creating installers is programming.
There is no tool that creates features at runtime in the MSI package, at least no MSI based tool. This complicates too much the installer logic, as you would need a very complex custom action that reads the contents of the folders found next to the installer and then generate entries in the following MSI tables: Files, Directory, Component, Feature, FeatureComponents. And then inter-connect all of this.
That is not something easy to do at all, and very error prone is tried by something how does not have extensive experience in building MSI packages.
have you considered/tried any non-MSI package builders?
What I like to do is compile a custom file to generate a C# file. I only need it to compile when its been changed but compiling everytime is ok.
When I looked around I kept finding reference to Custom Tool and found this pretty good article. I remember pre2010 I was able to have a build rule for extensions but it looks like that doesn't exist anymore? It allowed me to specify an extension and bin+args to run against when the file changed. Whats the closest thing to that? It looks like it no longer supported which is exactly what I want
Custom Tool requires me to mess around with registry, create a dll and requires VS SDK. Its way overkill for something I done with ease in the past.
How do I have visual studios run my exe to build a custom extension source file without going into overkill like custom tool above? Must work for C# project, C++ projects would be nice but not required.
I've just tried to generate *.exe files from Perl scripts by using Par::Packer, the tool works fine as expected.
The situation now is I would like to distribute my Perl based application as a group of utilities (exe files), for each of them there is a corresponding Perl scripts, and they are sharing some common modules (including Perl stuff) pretty much. This results in each of the generated *exe files are bloated by similar codes.
I tried to attach --dependency option to pp, which reduce the size in some extent, while it just move the perl.dll out of the packaged file, the common modules are still there. I think there should be some other approaches to resolve this.
Any suggestions? Thank you in advance.
http://cava.co.uk/ provides that out of the box, allows you to easily create a .msi style installer, with however many scripts you want available as .exe files (and all modules and everything else required is shared)
You could also pack Par::WebStart's perlws, and pack each app using its make_par, then invoke each app using appshortcut.lnk or appshortcut.bat, or appshortcut.exe which just does system "perlws.exe appshortcut.pnlp"
or you could turn all your utilities into modules (you should do that anyway), and then pack them all with pp into a single single .exe, then create
foo.exe bar.exe baz.exe ... which just do system "mybigexe.exe foo.exe"
change the icons... with exe_update (from cpan)
My solution has a library project which needs a special environment to be built (lots of external libraries and tools)... but it is not vital to our application. We'd like to avoid installing these tools when not necessary (most of our developers work on other parts of code).
We have created another project which has the same API, but has an empty implementation and is compilable without those external tools. I'd like to be able to easily switch between those projects and still get all the references in other projects correct.
I don't know VS/MSBuild very well, but willing to learn whatever is necessary. Is it possible? I am looking for ideas... We're using Subversion, and solutions involving some hacks inside VCS are also welcome.
It sounds as if your library project is one that can be separated from your primary solution, taking the tool baggage with it. Doing that, you could build the speciality solution separately, an link the compiled assembly from the main solution.
Create another build-configuration for your project.
So you will have at least 2 build-configurations e.g. Debug_SpecialNeeds and Debug.
For discussion, I'll assume you have a project directory containing your solution file, a "RealLibrary\RealLibrary.csproj" project file (your "real" library, with the dependencies), and a "MockLibrary\MockLibrary.csproj" file (your "mock" library, with the empty implementations).
If I understand correctly, you want to easily "swap" the MockLibrary for the RealLibrary in your solution, and vice-versa.
The easiest/hackiest way to do this, assuming your solution (and dependent projects) are configured to look for the "RealLibrary.csproj" project, is to rename the "RealLibrary" directory (it doesn't matter to what), and rename the "MockLibrary" directory to "RealLibrary" and rename "MockLibrary.csproj" to "RealLibrary.csproj". This will effectively "trick" your solution and dependent projects into loading the "mock library" even though they are referencing the "real library".
A slightly more complex (and perhaps cleaner) solution is to actually modify your "sln" and "csproj" files to reference "MockLibrary.csproj" instead of "RealLibrary.csproj". In the "sln" file, you'll need to change the path to the project in the section near the top:
Microsoft Visual Studio Solution File, Format Version 10.00
# Visual Studio 2008
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "RealLibrary", "RealLibrary\RealLibrary.csproj", "{E1714F9A-E1D9-4132-A561-AE2B4919391C}"
EndProject
You need to change that path "RealLibrary\RealLibrary.csproj" to "MockLibrary\MockLibrary.csproj". If you're going for completeness, you can change the name as well (or perhaps just use a generic name like "Library" for the name).
Likewise, in the dependent csproj files, you'll need to find all instances of the "ProjectReference" node where you reference "RealLibrary.csproj" and modify the path. These sections look like this:
<ProjectReference Include="..\RealLibrary\RealLibrary.csproj">
<Project>{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</Project>
<Name>RealLibrary</Name>
</ProjectReference>
You could relatively easily write some scripts to perform this swap. However, I think there's a deeper problem here that can be addressed more directly. I'll post that as a separate answer, but I wanted you to have the actual answer you were looking for first.
The deeper problem I see here is that your library "needs a special environment to be built", specifically because it depends on "lots of external libraries and tools". I would suggest that you NOT go down the path of creating the mock library, but instead focus on getting the library to build correctly without a special environment. You can achieve this by including all of those dependencies in source control along with your project, and reference those dependencies via relative paths inside your working copy. In my build environments, I try to avoid static environmental dependencies as much as possible (ideally limiting it just to the .NET framework itself).
To get the dependencies into source control, you can either check them directly into the project itself, or you can check them into a different location and then "reference" them in your project via svn:external definitions. In my environment, I have a separate "bin" repository used just for these kind of third party library dependencies, and then many dependent projects can pull them in via externals.
If you can eliminate your library's build-time environmental dependencies, your build will be much more robust and it will be much easier for developers to work with the project.