Utiliser nmake sur OSX?

Je suis en train de porter une application sur MacOS X - mais le système de construction du développeur d'origine utilise NMAKE, et idéalement, ils aimeraient le conserver au lieu de passer à un nouveau. J'ai réussi à faire fonctionner NMAKE sous OSX en utilisant wine (construit avec MacPorts) et ajouté le support d'Objective C aux fichiers de construction, et j'ai créé un wrapper PE 'run.exe' lié au Unix que le vin peut charger mais utilise POSIX à rappeler dans des choses comme gcc et ld, comme cela est décrit sur différents sites en ligne comme un moyen d'échapper à partir de vin dans Unix.Utiliser nmake sur OSX?

Cependant, j'ai quelques problèmes spécifiques. Ils sont assez mineurs pour que je puisse continuer avec le port, mais cela signifie que je dois parfois exécuter des builds plusieurs fois, à cause du timing.

Fondamentalement, lorsque wine.exe rappelle dans le shell et donc gcc, le lien entre les processus fils semble être rompu. gcc et ld ne renverront jamais un code d'erreur même en cas d'échec, car ils ne peuvent pas obtenir le code de sortie de leurs enfants engendrés. ar imprimera réellement il ne peut pas trouver son enfant et retourner immédiatement, causant des problèmes quand ld essaye de lier des fichiers d'objet aux bibliothèques qui sont encore assemblées.

Est-ce que quelqu'un d'autre a essayé quelque chose de similaire et vu le même problème, sur OSX ou ailleurs? Y a-t-il une solution évidente?

Source

2010-08-14 electric-monk

faciliter votre vie, passer à quelque chose comme CMake? ou maintenez des systèmes de construction séparés: xcode, visual studio, autotools ou makefiles raw gnu - pour moi ce que vous faites n'est pas à l'épreuve du temps –

Il y a la possibilité de passer à un système de construction complètement nouveau, mais évidemment ils veulent quelque chose fonctionnera à la fois sur Windows et OSX, fortement contre la maintenance de plusieurs systèmes. Ils ont également fortement préféré rester avec nmake, car c'est ce à quoi ils sont habitués :) Je pense que si ce n'était pas pour le problème du processus de vin de l'enfant, ce serait une solution entièrement à l'épreuve du futur, cependant. –

Le projet Rotor Microsoft .NET (SSCLI) inclut le code source, destiné à être construit sur OSX et ailleurs. Le code source de Rotor inclut le code source de NMake. Donc, faites travailler Rotor, puis utilisez Nmake. Même si vous préférez continuer à utiliser votre Nmake à base de vin, vous pouvez probablement apprendre de l'utilisation de Nmake sur Unix par Rotor, de l'utilisation de Gcc, etc.

Source

2010-12-09 04:56:33

C'est parfait, merci! Après beaucoup de piratage autour du code légèrement vieillissant, en modifiant le code et en contournant les scripts de construction de Microsoft, j'ai maintenant un binaire nmake brillant qui est natif d'OSX et fonctionne parfaitement. Mis à part toutes les choses que je devais réparer et la construction totalement brisée, Microsoft a fait un très bon travail d'emballage OSX (et Unix). –

Glad it aidé. Vous devriez poster vos changements quelque part, afin que les autres puissent bénéficier de votre travail! –

S'il n'y a rien d'étrange/incohérent par rapport au système de construction des développeurs d'origine, pourriez-vous écrire une conversion automatique de leurs fichiers make dans Unix make, et garder vos versions 'natives'?

(Builds être assez lourde de toute façon, sans complications supplémentaires)

Source

2010-08-14 15:37:34 JulesLt

J'ai envisagé l'idée de faire un convertisseur, mais je craignais que cela ne devienne un gros travail en lui-même - surtout lorsque la solution nmake-in-wine fonctionne * presque * parfaitement - nmake semble même gérer Unix des chemins sans trop réfléchir, c'est juste un problème de vin bizarre. –

Utiliser nmake sur OSX?

Répondre

Questions connexes