52
Sono un utente molto frequente di GNU Autotools (principalmente Autoconf, occasionalmente Libtool). Sto lavorando a un progetto in cui la portabilità sarà un punto critico. Eppure, il resto del team non si trova a proprio agio con lo m4. Ho this nella mia casella di posta da non uno, ma quattro persone:Alternative a Autoconf e Autotools?
In ogni caso, forse qualcuno potrebbe consigliarmi qualcosa Python o PHP based? Sto lavorando all'estremità C di un albero molto più grande; Posso essere sicuro che sia presente Python o PHP 5, in quanto prerequisiti.
La familiarità con m4 è irrilevante. Discutere contro autoconf a causa di m4 è come discutere contro C perché il compilatore usa un lexer generato da lex e gli sviluppatori non capiscono lex. Quando si utilizzano gli autotools, è possibile ignorare completamente m4 il 98% delle volte. Nel restante 2%, puoi anche ignorare m4! Di solito, se ti trovi ad avere problemi relativi a m4 è perché stai facendo qualcosa di fondamentalmente sbagliato. –
@WilliamPursell dopo un paio di anni da quando ho chiesto questo, sono tendenzialmente d'accordo. Ma il problema rimane - È semplicemente troppo facile imboccare un percorso fondamentalmente sbagliato che lo usa. E, quando vuoi un controllo di costruzione davvero granulare da configurare, alla fine premi M4. A meno che non mi sia sfuggito qualcosa? –
@TimPost Ho dovuto affrontare un argomento simile anni fa. Nessuno voleva imparare M4 (o niente se poteva essere aiutato). Il progetto è diventato una combinazione di script bash e python, oltre a un'orribile app C++ che utilizzava principalmente le macro in stile C. Infine, dopo aver avuto l'autorità di asciarlo dopo 6 mesi che il sistema si è complicato in modo arbitrario (app per C++ che chiama python e script di shell tramite 'system (2)'), ho scambiato questo pasticcio con uno script M4 di 200 righe. Non arriverò mai ad accettare "non vogliamo impararlo" come scusa valida. – DevNull