2009-02-27 9 views
6

私は約10のディレクトリに約500ファイルのソースコードを持っています。ディレクトリ構造をリファクタリングする必要があります。これには、ディレクトリ階層の変更やディレクトリの名前の変更が含まれます。C++ディレクトリ再構成

私はsvnバージョンコントロールを使用しています。リファクタリングには2つの方法があります:1つはsvnの履歴(svn moveコマンドを使用)を保存し、もう1つは保存せずに保存します。私はSVNプラグイン(SVNプラグイン)を使ってSVN履歴を保持するリファクタリングがずっと簡単だと考えています(ビジュアルスタジオはディレクトリ再構成にはまったく適合しません)。

しかし、コードは公開されていないので、履歴を保存しないという選択肢があります。

ヘッダーファイルがインクルードされている場所でインクルードディレクティブを変更する作業は依然として変わりません。私はpythonを使って小さなスクリプトを書くことを考えています - 現在のファイル名から新しいファイル名へのマップを受け取り、必要に応じて(sedのようなものを使って)名前を変更します。誰もこの種のディレクトリリファクタリングを行っていますか?あなたは良い関連ツールを知っていますか?

+0

コードベースでは、#include "maybe/some/stuff.h"のようなソースツリーのルートに基づくパスを使用し、#include "../../../stuff.h"のような相対パスは使用しないことをお勧めします。 – bk1e

+0

@ bk1e、そうです。 –

答えて

3

これを行うには#includeを書き直す必要がある場合は間違っていました。 #includesをすべて2レベルの深さで、アーキテクチャやOSの依存関係を整理するために2番目のレベル(sys/types.hなど)を使用するだけで、非常に単純なディレクトリ構造を使用するように変更してください。

次に、makeファイルを変更して、-Iパスを使用するように変更します。

Voila。このためにコードを再度ハックする必要はなく、何か問題が生じた場合にコンパイルが即座に爆発します。

歴史の部分では、私は個人的には、このようなことをするときにクリーンスタートをとる方が簡単です。古いものをアーカイブし、新しいリポジトリv2を作成し、そこから移動します。対抗措置は、変更の履歴がたくさんある場合、または既存のコードに対して多数の未解決の問題がある場合です。

ああ、あなたは良いテストをしていますが、あなたはすぐにリリースされてこれをやっていないのですか?

+0

同意 - 構造体はコードではなくビルド情報に属します。 Macコンパイラは、ディレクトリツリーを指定できるようにするために使用されていたので、あまりにも多くの明示的なパスで悩む必要はありませんでした。私がVisual Studioを使い始めたのは衝撃的でした! –

+0

"Makeファイルを変更するには-I include paths" - インクルードはあまり深くはありませんが、-I pathを複雑にしたくありません。各ディレクトリの最上位には、ディレクトリの「ファサード」を提供するラッパーが必要です。これがブーストの仕組みです。 1つのディレクトリだけを必要とするだけです。 –

+0

私はあなたのやり方がそれほど重要ではないと思っていますが、ラッパーファイルはビルドの仕組みを理解するためにコードを読み込まなければならないことを意味します。私はむしろMakefile内のすべてを見つけることができるだろう。 –

2

余分な時間がかかっても、私は履歴を保存します。コミットログを読み込み、関数Xがなぜ奇妙な方法で記述されているのか、これは実際には間違っているOliverによって書かれたため、これは実際にはオフラインのエラーです。

歴史を保存に対する引数は次のユーザーのために作らことができます。

  • あなたのコードは、開発者
  • 間冒涜と戦うようにあなたがのコミットの歴史を気にしない、恥ずかしいものを持っているかもしれませんあなたのコードは将来変更されたり維持されたりしないためです

コードベースでこの昨年のようにいくつかのディレクトリリファクタリングを行いました。あなたのコードが妥当な構造であれば、私はあなたの言語(Perlを使いました)で書かれたスクリプトを使って、仕事の75-90%を行うことができます。私の場合は、すべてのファイルを1つの大きなディレクトリに移動し、名前空間に応じて一連の入れ子になったディレクトリに移動しました。したがって、protocols protocols :: serialization :: SerializerBaseクラスを宣言したファイルは、src/protocols/serialization/SerializerBaseにあります。古い名前から新しい名前へのマッピングは些細なものでした。そのため、ツリー内のすべてのソースファイルで#includeを検索して置き換えるのは簡単でしたが、大きな変更でした。私たちが手で修正しなければならなかったいくつかの奇妙なエッジケースがありましたが、それはすべてを手作業で行うことや独自のC++パーサーを書くことよりもはるかに良いようでした。

2

svnの移動を行うためのシェルスクリプトをハッキングするのは簡単です。 で、tcshです。foreach F($ FILES)... endファイルのセットを調整します。 Perl & Pythonはより良いユーティリティを提供します。

本当に歴史を保存する価値があります。特に、いくつかのエキゾチックなバグを追跡しようとするとき。

https://stackoverflow.com/questions/573430/ c-include-header-path-change-windows-to-linux/573531#573531:歴史から学ばない人はそれを繰り返す運命にある、またはそのようないくつかのジャンク...すべてのファイルを変更するためとして

...同様の質問先日オーバーがでした

関連する問題