I'm following the instructions from here to build MonoDevelop on Mac OS X: Building MonoDevelop on OS X
I can build MonoDevelop just fine. I'd like to also build the MonoMac add in and use it.
The document says:
"To include addins from extras, manually copy their build directories
into the MonoDevelop.app directory, e.g.
cp -r ../../../extras/MonoDevelop.AspNet.Mvc/build/*
MonoDevelop.app/Contents/MacOS/lib/monodevelop/AddIns/MonoDevelop.AspNet.Mvc/"
However, I have no build directory under /extras/MonoDevelop.MonoMac.
I tried to follow this step to build extras:
"To include additional addins from extras in the build, instead of
using the Mac profile, use configure --select to select addins. This
will write the default profile. Next, replace the line in
profiles/default that begins with "main" with the one from
profiles/mac, then run configure again using the default profile."
But it does not give me the option to build the MonoMac extra.
Next, I try to compile the monodevelop.mdw. Again, I can build the main solution (MonoDevelop), but the extras fails with over 1000 errors.
Finally, I tried to take my existing monomac and macdev plugins and copy them into my master monodevelop.app bundle. But this breaks add solution/project dialog whenever I try to select a MonoMac project - it fails to load the Monodevelop.ide DLL.
Any advice on where I am going wrong would be appreciated.
I was not able to make this work following the directions on the MonoDevelop site. Even manually adding the extras/MonoDevelop.MonoMac extra to the profile did not work.
In the end, I build MonoDevelop from source, using the mac profile.
Then I got the latest MonoMac pieces, and build them from source. I used
make update
to install into my installed copy of MonoDevelop.
Then, I manually copied the following packages from my installed MonoDevelop to my newly compiled version from master:
MacPlatform.dll
MonoDevelop.iPhone
MonoDevelop.MacDev
MonoDevelop.MonoMac
Xamarin.Ide
Any everything now works :)
Related
I usually use rvm, but also need to work with a custom Ruby build. I understand that when I go to the RubyMine "Settings", "Languages & Frameworks", "Ruby SDK and Gems" dialog, I need to press "+" and select "New Local with Custom Configurator".
On that dialog, the Ruby interpreter path is self explanatory, but I don't know which environment variables I need to specify in the "Custom Configurator" session. What information needs to go there?
I am using RubyMine 2021.1 on both Mac OS and Linux. I need to be able to debug, which means that when RubyMine installs the debug support gems, they need to go to the right location, and be found from that location.
It turned out that all I needed to specify there was my GEM_HOME:
env GEM_HOME=/opt/my-custom-ruby/gems/2.7.0
I was surprised that I didn't also need to explicitly set the path to the directory containing the Ruby interpreter (for commands other than ruby, such as bundle), but I guess RubyMine does that for me. Or, maybe it doesn't, and I just haven't encountered an error yet.
Edit: It turns out I did have an issue with a gem not being found. I added to that env command and the problem went away, but I'm not really sure yet if that was the issue or if adding both GEM_PATH and PATH were necessary. Here is what I wound up with:
env GEM_HOME=/opt/my-custom-ruby/gems/2.7.0 GEM_PATH=/opt/my-custom-ruby/gems/2.7.0 PATH=/opt/my-custom-ruby/bin/ruby:$PATH
EDIT 2021-12-24
I just tried this again on a new installation and the above did not work. I was getting build errors saying that I needed to install the development tools. It turned out that when specifying the path in the
Custom Configurator field I needed to include the path for the gcc compiler. I just put most of the paths in my login PATH value there, and the gem installation succeeded.
One of my Open Source projects uses Packages to build the macOS installer. After GUI-based setup of the pckgproject file, the installer build can be easially invoked from the command line through the packagesbuild command.
I'm now setting up a GitHub Actions based build workflow, running on the GitHub-hosted runners, which should ideally create a ready-to-use installer, so I need to invoke packagesbuild during that process. Unfortunately packagesbuild is not available on the macos-10.15 runner used. I don't see any option to install it during the workflow run, as it's not available through e.g. homebrew but maybe I'm overlooking something. Is there any option I'm overlooking beneath rebuilding my installer and switching to pkgbuild?
I have made a VS2010 project which installs MySQL by calling MySQLInstallerConsole.exe with necessary arguments. This works perfectly however, when I try to run this project's exe as a custom action it executes the exe but MySQL is not installed.
I checked the log file for MySQL exe and it had the following error:
Error 50: Package Name State change request failed.
What does this really mean, any solutions?
There are at least a couple of things that have something to do with this:
I believe the MySQL installer is an MSI file according to this:
http://dev.mysql.com/downloads/installer
You cannot install an MSI from a custom action of a Visual Studio setup because recursive calls to MSI installs are not allowed.
In a Everyone install custom actions run with the SYSTEM account, and installs are not often expecting this if they want to install files in user-profile folders because the SYSTEM account doesn't have any.
You need to bootstrap this somehow, and I think people are often using the WiX Burn bootstrapper for that. You define the ProductCode, name etc of the product and define how to install it.
I have a solution that is primarily developed in Visual Studio 2012. I would like to develop in MonoDevelop without major incompatibilities.
Thus far, I have installed mrward's nuget addin for MonoDevelop and things work if I manually add each package in packages.config through that interface. However, this is highly onerous. This addin doesn't have support for automated package restore as of this writing.
I downloaded nuget.exe from CodePlex ("NuGet command line utility", as it's labeled). I use a simple find/xargs combination to install all required packages:
find . -name packages.config | xargs -I '{}' mono nuget.exe install '{}'
This creates several dozen directories in the directory from which it is run instead of putting things under packages/ as expected, and it also doesn't touch the project files so MonoDevelop still thinks that it should be looking for package references in the directory from which MonoDevelop was started.
I therefore opened MonoDevelop from the working directory that contains all of these package folders, and I still get invalid references. I think this is probably because the project is looking for package_name/ reference, but the folders are name package_name.version/ in the working directory.
Any suggestions for a sane, simple way to interact with this solution? I'm next going to try modifying my shell command so that it automatically drops to project/packages and runs nuget from that directory.
Did you try using the -o command line parameter with NuGet.exe? You can use that to get the packages to install into a particular packages folder.
The NuGet addin for MonoDevelop supports package restore from version 0.6 or above. Right click your project and select Restore Packages. This will download all the packages defined in your packages.config for all projects in the solution. It uses NuGet.exe to do this.
Another way to get this working is to use the custom NuGet MSBuild target so the package restore happens at build time when using xbuild. It would require some manual editing of project files though. Under the covers the custom MSBuild target just uses NuGet.exe with a similar command line to what you have already just with the output directory option specified. So I would try the command line approach since that will be less work.
You would have to get the following files from the NuGet repository on codeplex:
NuGet.exe
NuGet.targets
NuGet.config
Put these in a directory somewhere. Typically these are put in a .nuget directory in the same directory as your solution file. Then you need to edit your project files to include the NuGet.targets file and also define the SolutionDir property. So something like this:
<SolutionDir Condition="$(SolutionDir) == '' Or $(SolutionDir) == '*Undefined*'">..\..\</SolutionDir>
<Import Project="$(SolutionDir)\.nuget\NuGet.targets" />
You will also need to enable package restore on your machine. You can do this using the NuGet addin for MonoDevelop in the Options dialog. Under Linux this is available from the Edit menu under Preferences. Then look in the NuGet - General options and there is a checkbox for enabling package restore.
There is an example project on GitHub created by Jonathan Channon which uses package restore and works when building with xbuild inside MonoDevelop. There is also an issue on GitHub about using NuGet restore on Linux which might be helpful.
Update: 2014-05-14: NuGet addin for MonoDevelop now supports package restore.
Is there a way to update just one bundle without updating every bundle in your deps file? I am currently using "php vendors install" to install all vendor bundles and am not aware of any commands that will update just one bundle at a time.
1) Just open your deps file (./deps)
2) Remove all bundles except the one you want to update and save the deps file
3) Let's run the command: php bin/vendors update
It will update the bundle.
4) Go back in your deps file and rewrite all the previous removed bundle lines !
Cheers !
Short version:
The "best way" to do this depends on your setup. If you've run "php bin/vendors update" before, then it would probably be best to remove the line for the bundle you want to update from your deps.lock file, then run "php bin/vendors install" from your base symfony folder.
Long version:
I think some clarification of what the various vendor commands do is in order.
1) php bin/vendors install
This command downloads (if necessary) and installs vendor bundle source files into symfony/vendor. This command will first look at deps.lock to see what git commits/versions are listed there, then it will look at your deps file to see what versions are listed there. If no version is specified in either for a certain bundle, it will download the most recent version of the bundle code for that bundle. If a version is found, it will download and install that version of the vendor bundle code.
This command will not put anything in deps.lock.
2) php bin/vendors install --reinstall
This command does the same thing as php bin/vendors install, except it will always download the code before installing it into symfony/vendor.
This command will not put anything in deps.lock.
3) php bin/vendors update
This command will ignore deps.lock, and will download (if necessary) and install the versions of bundle code listed in the deps file into symfony/vendor.
After it is done downloading and installing code, it will put the git commit id / version of the downloaded code for each bundle into your deps.lock file. That way, when you go to run one of the install commands listed above, the version of code that is downloaded won't change unless you remove the related line from the deps.lock file or if your run the update command again.
The idea behind the deps.lock file is that it prevents you from accidentally upgrading your bundles to a more recent bug non-working version of the 3rd party bundle code. Symfony and it's bundles are under constant development, so changes (even if they're not bugs) happen pretty frequently and will break your code. You'll probably want to get your versions locked down in deps.lock as soon as possible and only update when you feel like going out of your way to do so.
Once you've locked down your bundle versions in deps.lock, you'll just need to remove the related line from your deps.lock file the run one of the install commands to update a specific bundle, like I said in the short answer above. If you then want to lock that code down to the version you just installed, you'll want to add a line to deps.lock yourself, or remove everything from deps and run php bin/vendor update like the answer above indicates.